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This  report  was  prepared  by  the  Institute  for  Defense  Analyses  (IDA)  for  the  Office 
of  the  Secretary  of  Defense,  Manpower,  Reserve  Affairs  and  Logistics  Under  Contract 
Number  MDA  903  84  C  0031,  Task  Order  T-3-192,  "R&D  Support  to  Improve  Force 
Readiness." 

The  issuance  of  the  report  answers  the  specific  task  to  "...assemble  a  group  of  both 
industry  and  government  personnel... experienced  in.. .computer-aided  technologies  for 
automation  of  support  procedures  in  order  to  examine  issues. ..include(ing)  the 
subcontractor  level,  inventory  management  techniques,  etc.  At  present  these  issues  are 
being  addressed  individually  without  apparent  consideration  of  their  interaction  in  meeting 
the  total  DoD  objective...to  evolve  a  general  plan  for  automated  support  of  DoD  operating 
systems  which  addresses  the  problems  of  interaction  between  the  different  systems  now  in 
use  or  evolving,  and  the  various  approaches  being  taken  by  DoD  to  address  its  readiness 
problems." 
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POLICY  AND  LEGAL  CONSTRAINTS  SUBGROUP 


Objective 

To  identify  DoD  and  industry  policies  and  existing  planning  standards  (e.g.,  Mil- 
Std  1388-2A),  relevant  laws  (e.g.,  PL96-511,  Paperwork  Reduction  Act),  and  relevant 
regulations  (e.g.,  DAR  and  FAR)  which  facilitate  or  constrain  pursuit  of  the  CALS 
strategy.  The  resulting  list  should  then  be  grouped  into  generic  categories  and  cross¬ 
checked  with  policy  and  legal  issues  evolving  from  the  other  subgroups  in  order  to  develop 
a  set  of  recommended  changes  necessary  to  facilitate  the  CALS  strategy. 


Members 

Chairman:  Herman  Correale 

Vice-Chairman:  Emerson  Cale 
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EXECUTIVE  SUMMARY 


Computer-Aided  Design  (CAD)  and  Computer-Aided  Manufacturing  (CAM)  have 
widely  computerized  the  design  and  manufacturing  processes  and  provided  extensive  data 
bases.  Computer-Aided  Logistics  Support  (CALS)  is  the  computerization  of  Integrated 
Logistics  Support  (ILS)  processes.  CALS  links  the  activities  of  each  ILS  element, 
improves  their  interfaces  with  each  other,  with  government  departments,  and  with 
contractors.  Integration  of  CALS,  CAD  and  CAM  data  provides  a  relational  data  base  that 
will  serve  logistics  support  planners  over  an  entire  acquisition  program,  beginning  with  the 
pre-concept  phase  and  progressing  through  disposal.  Ultimately,  CALS  will  be 
implemented  across  all  weapon  systems  and  all  military  Services. 

The  mechanisms  for  supporting  CALS  implementation  should  include  the  data 
bases,  computers,  communications  linkages,  recording  media,  software  and  hardware 
necessary  to  provide  compatibility  among  the  participating  contractors  and  military 
Services.  This  information  network  must  be  responsive  to  using  activities  including  the 
System  Program  Office,  logistics  centers,  government  laboratories  and  using  commands. 

Interface  standards  are  required  to  describe  relational  data  base  criteria  for  CAD, 
CAM  and  CALS.  These  standards  would  specify  requirements  for  interchangeability, 
transportability  and  access  management  of  digitized  data.  Interface  standards  should 
describe  how  discrete  systems  work  with  each  other,  rather  than  how  to  design  and 
develop  each  element  of  the  system.  A  Standard  Strategic  Program  Plan  is  required  to 
identify  standardization  opportunities  and  provide  roadmaps  for  standards  development. 

Standards  are  also  needed  to  define  common  terms  and  data  elements  for  each  ILS 
discipline.  A  DoD  policy  should  require  the  establishment  of  a  CALS  standard  that  would 
act  as  an  index  and  dictionary  for  data  required  for  development,  acquisition  and  post¬ 
production.  A  Joint  industry/govemment  team  should  be  tasked  to  prepare  the  CALS 
standards. 

Data  access  and  file  transfer  is  a  policy  issue  to  be  resolved  by  DoD.  The 
government  needs  to  define  the  CALS  logistics  data  requirements  and  integrate  these  with 
their  existing  automation  systems.  Policy  for  data  transfer  should  assure  that  contractor 
files  would  not  have  to  be  recreated  by  the  government  Access  or  acquisition  of  data  bases 
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Programs  exist  or  are  under  development  for  automating  technical  information. 
One  of  the  foremost  purposes  of  CALS  is  to  focus  these  projects  on  enhanced  logistics 
support  through  integrated  computer-aided  operations.  DoD  strategy  should  include 
development  of  selected  CALS  building  blocks  through  the  application  of  technology- 
related  pilot  demonstration  programs.  CALS  policy  should  encourage  program 
demonstrations  beginning  with  IR&D/CR&D  technology  development.  As  automation  of 
selected  pilot  program  modules  is  achieved,  interchangeability  and  transportability  of 
digitized  data  will  be  demonstrated.  An  evolutionary  approach  will  permit  systematic 
progress  development  and  integration  of  all  required  CALS  building  blocks.  Field 
implementation  of  CALS  will  begin  with  new  weapon  system  acquisitions  and  gradually 
expand  to  all  weapon  systems. 

The  present  legal  and  regulatory  environments  generally  encourage  the  rapid 
implementation  of  automated  processes  offered  by  CALS.  However,  the  Paperwork 
Reduction  Act,  when  literally  interpreted,  requires  that  all  information  collection  requests  be 
inventoried  and  displayed  and  control  numbers  and  expiration  dates  assigned.  Proprietary 
and  software  data  rights  issues  have  been  highlighted  as  areas  of  concern  to  industry. 
Concerns  for  legal  issues  could  be  eliminated  by  a  DoD  policy  for  transfer  of  digital  data. 


GLOSSARY 


ADP 

- 

Automatic  Data  Processing 

ANSI 

- 

American  National  Standards  Institute 

CAD 

- 

Computer-Aided  Design 

CADD 

- 

Computer-Aided  Design  Definition 

CAE 

- 

Computer-Aided  Engineering 

CAM 

- 

Computer-Aided  Manufacturing 

CALS 

- 

Computer-Aided  Logistics  Support 

CDRL 

- 

Contractor-Furnished  Equipment 

CRAD  (CR&D) 

- 

Contract  Research  and  Development 

DAR 

- 

Defense  Acquisition  Regulation 

DDN 

- 

Defense  Data  Network 

DLA 

- 

Defense  Logistics  Agency 

DMSSO 

- 

Defense  Materiel  Specifications  and  Standards  Office 

DoD 

- 

Department  of  Defense 

DoDD 

- 

Department  of  Defense  Directive 

FAR 

- 

Federal  Acquisition  Regulation 

GFE 

- 

Government-Furnished  Equipment 

GKS 

- 

Graphics  Kernel  System 

IGES 

- 

Initial  Graphics  Exchange  Specifications 

ELS 

- 

Integrated  Logistics  Support 

ERAD  (IR&D) 

- 

Independent  Research  and  Development 

ISO 

- 

International  Standards  Organization 

LSA 

- 

Logistics  Support  Analyses 

LSAR 

- 

Logistics  Support  Analyses  Record 

Mil-Std 

- 

Military  Standard 

NAPALPS 

- 

North  American  Presentation  Level  Protocol  Standard 

NBS 

- 

National  Bureau  of  Standards 

PHIGS 

- 

Programmer's  Hierarchical  Integrated  Graphic  Standard 

SDRL 

- 

Sellers  Data  Requirements  List 

SGML 

- 

Standard  Generalized  Markup  Language 

VDI 

- 

Vertical  Device  Interface 

VDM 

- 

Vertical  Device  Metafile 

COMPUTER-AIDED  LOGISTICS  SUPPORT  (CALS) 
POLICY  AND  LEGAL  CONSTRAINTS  SUBGROUP 


A.  CALS  CONCEPT 

I.  General 

Implementation  of  Computer-Aided  Design  and  Computer-Aided  Manufacturing 
(CAD/CAM)  concepts  will  help  reduce  the  efforts  associated  with  designing  and 
developing  a  new  weapon  system,  as  well  as  the  development  time  from  go-ahead  to 
production  delivery.  Proper  emphasis  on  weapon  system  logistics  support  is  essential  for 
sustained  combat  and  peacetime  operations  and  dictates  that  the  data  available  in  CAD/CAM 
be  electronically  coupled  to  a  computer-aided  logistics  data  base.  This  relational  data  base 
concept,  in  conjunction  with  advanced  computer  networks,  presents  opportunities  to  more 
fully  automate  and  integrate  the  logistics  support  processes.  However,  before  this  can 
happen,  a  definite  change  in  mind  set  is  required. 

The  advantages  of  computer-aided  logistics  support  are  many  and  varied.  As  new 
data  auditing  and  approval  techniques  become  available,  contracts  for  support  material  and 
services  could  be  placed  electronically,  and  data  transfer  from  contractor-to-govemment 
and  govemment-to-govemment  agencies  could  be  handled  electronically.  Reprocurement 
data  would  be  immediately  available,  and  program  management  decisions  could  be  based 
on  near-real-time  data  accessible  to  both  government  and  contractor  agencies.  Currently, 
and  in  contrast,  vast  amounts  of  redundant  data  on  current  programs  inundate  the  logistics 
community  with  paper  and  burden  the  logistics  support  community  with  attempting  to  find 
the  "real"  problem. 

Inherent  to  the  effective  implementation  of  CALS  is  a  clear  understanding  of  what  is 
required  by  the  government.  The  CALS  standards  must  include  compatible  data  base 
construction  and  maintenance  procedures  to  ensure  uniformity  of  data  elements  common  to 
more  than  one  user.  Also,  the  media  used  to  transmit  data  must  be  specified.  Mass 
common  data  deliverables  may  best  be  transferred  by  physically  relocating  discs  or 
magnetic  tapes  possessing  common  data  elements  and  data  format.  Frequent  transfer  of 
small  numbers  of  data  elements  would  be  accomplished  using  on-line  video  display 
terminals.  Maximum  use  of  embedded  software  routines  could  be  used  to  tailor  repetitive 
reports  to  a  common  format. 


2. 


While  CAD  and  CAM  computerize  the  design  and  manufacturing  processes  by 
providing  extensive  digital  data  bases,  CALS  is  the  computerization  of  the  Integrated 
Logistics  Support  (ELS)  processes.  CADS,  coupled  with  the  as-designed  and  as-built  data 
available  in  CAD  and  CAM,  will  form  a  comprehensive,  manageable  data  base  containing 
all  elements  essential  for  enhanced  logistics  support.  The  CALS  data  base  would  become 
the  "point  of  reference"  for  government  and  industry  and  serve  all  acquisition  and  logistics 
support  agencies. 


CALS  must  take  advantage  of  existing  and  emerging  information  systems 
technology  to  improve  productivity  and  quality  of  the  logistics  support  processes  by  (1) 
actively  influencing  the  design  process,  and  (2)  automating  the  development,  production, 
delivery  and  maintenance  of  the  logistics  support  products  and  resources. 


The  CALS  objectives  are  summarized  as  follows: 


a.  Improve  product  reliability,  maintainability  and  supportability  by  influencing 
design  through  interaction  between  CAD  and  CAM. 


b.  Improve  productivity  by  reducing  manual  logistic  processes  and  thus  reduce 
system  flyaway  cost. 

c.  Increase  the  effectiveness  of  logistics  planning  by  permitting  early  identification 
of  logistics  support  needs. 


d.  Improve  the  logistic  support  acquisition  process  and  configuration  management 
through  integration  of  CAD,  CAM  and  CALS  information. 


e.  Ensure  continued  availability  of  current  product  definition  data,  etc.,  for  follow- 
on  support,  configuration  management,  spares  reprocurement  and  post¬ 
production  support. 


CALS  would  span  the  entire  program  life  cycle  beginning  with  the  pre-concept 
phase  and  progressing  through  product  disposal.  Ultimately,  it  would  be  implemented 
across  all  weapon  systems  and  all  military  Services. 

As  the  following  paragraphs  illustrate,  CALS  ultimately  should  include  logistic 
modeling,  accounting,  interdependency  "trees"  and  analyses  [particularly  Logistic  Support 
Analysis  (LSA)]. 
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CALS  would  apply  to  the  full  depth  and  span  of  logistics  activities,  that  is,  to  all 
ILS  element  functions  as  defined  in  DoDD  5000.39.  These  include  Supply  Support; 
Technical  Data;  Facilities;  Manpower  and  Personnel;  Packaging,  Handling,  Storage  and 
Transportation;  Training  and  Training  Support;  Support  and  Test  Equipment;  Computer 
Resources  Support;  Maintenance  Planning;  and  Design  Interface  activities  including 
Reliability,  Maintainability  and  Human  Factors. 

A  function  of  ILS  is  to  influence  the  initial  design  concept  fo  a  weapon  system  so  as 
to  enhance  supportability.  In  the  preliminary  design  stage,  the  logistics  data  base  needs  to 
be  linked  to  the  product  definition  process  (CAD),  thus  providing  the  basis  for  influencing 
the  design,  automating  LSA  and  making  logistics  simulations  assessments  (refer  to 
Figure  1).  Alternative  design  approaches  to  the  support  concept  will  be  considered  based 
upon  cost  effectiveness  tradeoffs.  Given  more  "real  time"  availability  of  the  results  of 
logistics  analyses,  logisticians  will  have  the  opportunity  to  further  influence  the  design,  and 
the  resultant  design  would  be  subsequently  analyzed,  via  the  LSA  process,  to  determine  the 
best  mix  of  support  resource  requirements.  The  data  elements  required  for  the  LSA 
process  would  reside  in  an  ILS  data  base.  The  ILS  requirements  resulting  from  the  LSA 
process  would  be  available  to  develop  the  support  resources  through  a  series  of 
computerized  support  element  output  modules. 

The  logistics  data  elements,  residing  in  the  ILS  data  base,  would  be  as  agreed  upon 
by  the  government  and  the  contractor,  identified  in  the  contractual  CALS  standard,  and 
tailored  to  each  specific  program.  Furthermore,  these  data  elements  could  be  electronically 
transmitted/called-up  to  user  terminals.  Such  computer  transparency  permits  other  software 
applications  such  as  automated  technical  manuals,  training  courses  and  program 
management  plans. 

The  CALS  data  base  would  further  provide  the  government  with  enhanced  logistics 
support  capabilities  for  the  post-production  phase.  Technical  information  required  for 
spare  parts  provisioning  and  modification  efforts  would  be  current  and  accessible. 
Maintenance  of  data  files  could  be  assumed  by  government  agencies,  as  required,  with  no 
loss  of  essential  data  and  without  the  expense  of  recreating  a  weapon  system  file. 

CALS  would  require  hardware,  software  and  standards  necessary  to  computerize 
all  logistics  support  data  and  provide  a  compatible  link  among  all  government  and  industry 
users.  Design,  manufacturing  and  logistics  data  bases  would  have  to  be  interactive 
(computer  transparent)  and  mutually  supportive.  Interactive  capability  would  ensure  that 
selected  data  from  CALS,  CAD  and  CAM  could  be  retrieved  by  all  logistics  support 
agencies  as  required.  Mutually  supportive  programs  would  ensure  current  data. 


Finally,  CALS  would  not  permit  indiscriminant  data  changes.  "Read  only"  or 
"write"  capabilities  would  be  attached  to  passwords  to  ensure  security  and  accuracy  of  data. 
The  computerized  data,  available  to  all  users,  could  eliminate  much  of  the  hard  copy  report  - 
ing  required  by  today's  CDRLs.  Key  principles  of  CALS  are  summarized  in  Table  1. 


Table  1.  COMPUTER-AIDED  LOGISTICS  SUPPORT  KEY  PRINCIPLES 


•  Logistic  design  criteria,  including  lessons  learned  and  field  data,  must  interact  with 
the  design  data  base  (CAD)  to  influence  design  for  supportability. 

•  Supportability  design-to-criteria  and  design  rules  (algorithms)  must  be  developed 
and  must  interact  with  CAD. 

•  Approved  logistic  support  analyses  must  control  publications,  personnel,  training, 
training  equipment,  support  and  test  equipment,  spares  and  facility  requirements 
in  CALS. 

•  CALS  must  contain  real-time  logistic  support  planning/scheduling  information. 

•  CAD  and  CAM  data  bases  should  interact  with  the  CALS  data  base. 

•  Source  of  CALS  data  must  be  computer-transparent  to  the  user. 

•  CALS  must  have  provisions  for  logistics  modeling  and  O&S  cost. 

•  CALS  should  be  linked  to  customer  field  data  reporting  systems. 


B,  POLICY  ISSUES  AND  RECOMMENDATIONS 

I.  Key  Policy  Issues 

The  key  policy  issues  are  as  listed  below: 

(1)  Near  term  and  long  range  goals  to  achieve  interoperability  and 
interchangeably  of  electronic  information  do  not  exist. 

(2)  Existing  policies  do  not  support  a  minimum  set  of  standards  for  acquiring 
and  transferring  electronic  information  to  the  government  users. 

(3)  A  standardized  set  of  data  elements  for  electronic  information  within  the 
weapon  system  logistic  support  acquisition  process  does  not  exist. 

(4)  Policies  do  not  encourage  computer-aided  techniques  to  improve  integration 
of  logistics  considerations  into  the  early  stages  of  design. 

(5)  Although  not  a  unique  CALS  issue,  the  proprietary  data  rights  and 
acquisition  of  computer  software  is  a  CAD/CAM  issue  that  will  impact 
CALS.  This  is  especially  true  when  considering  government  access  to 
contractor's  CAD/CAM  files. 

(6)  The  access  or  acquisition  of  data  bases  is  an  issue  to  be  addressed.  The 
government  should  consider  procuring  information  or  access  to 
information,  not  data  bases. 


DoD  policy  issued  10  March  1983  states:  "All  DoD  ADP  systems  and  data 
networks  requiring  data  communications  services  will  be  provided  long- 
haul  and  area  communications,  interconnectivity,  and  the  capability  for 
interoperability  by  the  Defense  Data  Network  (DDN)."  Logistics  data  traffic 
will  be  substantial  and  traffic  priorities  complex  and  many  exceed  DDN 
capabilities. 


The  general  policy  recommendations  are  as  listed  below: 

( 1 )  DoD  policy  should  establish  digital  data  transfer  as  the  preferred  method  for 
acquiring  engineering  drawings,  technical  manuals,  and  other  weapon 
system  acquisition  support  data. 

(2)  DoD  should  require  the  use  of  existing  and  emerging  industry  standards 
(such  as  IGES,  SGML,  GKS,  VDI,  VDM,  PH1GS  and  NAPLPS)  for 
accomplishing  such  digital  data  transfer  wherever  possible. 

(3)  DoD  policy  to  actively  promote  development  of  digital  data  systems  should 
be  strengthened  through  revision  of  the  DoD  Instruction  5000.19  policy  for 
management  and  control  of  information  requirements. 

(4)  A  joint  industry/govemment  team  should  be  tasked  to  prepare  a  CALS 
standard. 

(5)  CALS  policy  should  encourage  pilot  program  demonstrations  during 
IR&D/CR&D  technology  development 

(6)  CALS  policy  should  recognize  the  acceptance  of  alternate  delivery  media. 


It  is  recommended  that  a  Strategic  Program  Plan  be  prepared  by  the  Defense 
Materiel  Specifications  and  Standards  Office  (DMSSO)  to  identify  standardization 
opportunities  and  provide  a  detailed  roadmap  to  develop  standards  needed  for  long  range 
support  of  CALS  initiatives,  especially  in  the  areas  of  data  bases,  data  elements, 
communications,  graphics  and  textual  standards.  The  Program  Plan  for  digitized 
information  should  identify  ways  and  means  to  promote  DoD's  participation  and  support  of 
efforts  by  voluntary  standards  organizations  such  as  the  American  National  Standards 
Institute  (ANSI)  and  the  International  Standardization  Organization  (ISO). 


A  high  level  standard  for  handling  the  exchange  of  electronic  information  and  data 
such  as  ANSI's  IGES  and  proposed  SGML  should  be  considered  for  adoption  by  DoD  to 


enforce  future  interchangeability  and  transportability  of  digitized  information  between 
Services,  agencies,  and  contractors. 


A  top  level  MIL  Standard  on  interfaces  for  digitized  information  is  necessary  to 
facilitate  the  acquisition  and  use  of  digitized  data.  Timely  data  access  for  government 
agency  use  is  the  major  objective,  not  data  base  acquisition  or  real-time  access  to  all 
information.  Issues  to  address  are  as  follows: 

( 1 )  Integration  of  various  information  program  requirements  and  identification 
of  major  data  repositories  that  can  manage  and  maintain  digitized  data  for 
each  of  the  Services  are  required.  This  should  include  digitized  information 
for  ILS  support  as  well  as  digitized  data  for  product  definition  data, 
CAE/CAD  engineering  data,  manufacturing  data  (CAM)  and  procurement 
data. 

(2)  Formal  validation  requirements  and  facilities  for  validating  translators 
(compilers)  need  to  be  established  to  ensure  transportability  (interface)  of 
the  various  data  elements  and  to  permit  communication  between  the 
participants  (industry  and  government  agencies),  as  well  as  between 
CAE/CAD/CAM  and  CALS. 

(3)  The  CAD,  CAM  and  CALS  standards  are  subset  standards  which  relate  to  a 
top  level  interface  standard  for  information  transmission  and  access 
management  (graphics  and  text).  The  general  relationship  of  data  base 
standards  to  the  top  level  standard  is  illustrated  in  Figure  2. 


Logistic  STDs 

(Mil-Std-1388-1A 
etc.)  | 

Specifications 


Figure  2.  GENERAL  RELATIONSHIP  OF  DATA  BASE 
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(1)  General  Discussion.  Developing  a  comprehensive  set  of  standard  data 
element  definitions  for  commonly  used  logistics  parameters  is  a  major  challenge.  Many 
programs  exist  or  are  under  development  today  for  automating  technical  information.  An 
output  of  CALS  is  the  integration  of  these  programs  to  enhance  computer-aided  operations. 
In  order  to  implement  efficiently  this  multi-weapon  system,  multi-Service  concept, 
standards  are  needed  to  define  common  data  elements  and  data  requirements  in  each  ILS 
discipline. 

Logistics  Support  Analysis  (LSA)  and  the  Logistics  Support  Analysis  Record 
(LSAR)  provide  a  model  for  the  development  of  a  CALS  standard  defining  data  elements 
and  data  requirements.  MIL-STD- 1388-1 A  identifies  the  LSA  tasks  to  be  accomplished 
during  weapon  system  acquisition.  LSA  documentation  records  the  results  of  those  tasks. 
Data  produced  as  a  part  of  that  LSA  documentation  are  delivered  by  the  performing  activity 
in  accordance  with  data  element  definitions,  data  item  descriptions,  and  reports  contained  in 
MIL-STD- 1388-2A,  which  describes  LSAR  requirements.  Neither  standard  specifies  how 
the  performing  activity  should  accomplish  the  LSA  tasks,  or  which  LSAR  data  the 
requiring  activity  should  specify  to  meet  weapon  support  needs. 

MIL-STD- 1388-2 A  also  has  taken  the  first  (albeit  incomplete)  step  in  creating  a 
central  data  element  dictionary  supporting  the  data  requirements  of  the  acquisition  logistics 
and  engineering  (reliability  and  maintainability)  communities.  It  not  only  supports  logistics 
support  analysis,  but  also  the  technical  data  requirements  of  the  provisioning  community. 
To  achieve  the  objectives  of  a  CALS  standard  applicable  to  all  ILS  disciplines,  data 
elements  for  other  logistic  support  disciplines  must  be  added,  i.e.,  training,  technical 
publications,  etc.  In  order  to  accomplish  this  task,  functional  specialty  groups  in  the  DoD 
acquisition  arena  must  participate  and  cooperate  in  the  development  of  a  single  CALS 
standard.  Task  and  functional  requirements  of  those  individual  specialty  groups  should 
continue  to  be  identified  by  task-oriented  standards  such  as  MIL-STD-1388-1A.  Data 
element  definitions,  data  item  descriptions  and  electronic  report  format  options  should  be 
consolidated  into  a  single  CALS  standard. 


production.  An  evolutionary  approach  to  development  of  this  CALS  standard,  beginning 
with  the  foundation  laid  by  MIL-STD- 1388-2A,  will  facilitate  progressive  application  to 
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ongoing  (existing)  programs  and  permit  early  application  to  new  weapon  system 
acquisitions. 

(2)  Approach  to  CALS  Standard  Development.  The  approach  to  the 
development  of  a  CALS  standard  must  recognize  six  basic  criteria: 

(1)  Existing  logistics  tasks  identified  in  present  logistic  MIL-STDs  (i.e.,  MEL- 
STD- 1388-1  A,  etc.)  and  specifications  are  to  be  retained. 

(2)  Existing  logistics  data  requirements  and  DIDs  will  be  reviewed  to  eliminate 
present  data  element  duplication  and  inconsistency. 

(3)  The  CALS  standard  will  reduce  and  consolidate  the  number  of  present 
logistic  DIDs. 

(4)  The  CALS  standard  will  reference  the  current  logistics  MIL-STDs  which 
should  be  retained. 

(5)  The  CALS  standard  would  encourage  tailoring  for  each  program 
application. 

(6)  The  CALS  standard  would  be  the  primary  contract  instrument  for 
identifying  logistic  information  requirements. 


e.  Graphics  Standard 

DoD  should  consider  specifying  the  Initial  Graphics  Exchange  Specification  (IGES) 
as  the  standard  for  delivery  of  engineering  drawings  and  product  definition  data. 

The  Naval  Sea  System  Command  has  issued  two  policy  instructions  that  require  the 
use  of  the  IGES  for  this  purpose.  These  policy  instructions  could  be  tailored  by  DoD  to 
provide  graphics  standards  for  all  military  Services. 

The  first  is  NAVSEA  Instruction  5230.8,  "Transferring  Technical  Data  Among 
Navy  and  Contractors'  CAD/CAM  Systems,"  dated  23  August  1984.  This  instruction 
requires  that  IGES  Version  2.0  be  used  in  exchanging  product  definition  data  among 
participating  CAD/CAM  systems  except  for  work  under  the  cognizance  of  the  Deputy 
Commander  for  Nuclear  Propulsion,  NAVSEA  08.  The  instruction  also  requires  that: 

•  IGES  Version  2.0  will  be  invoked  in  all  new  contracts  involving  transfer  of 
CAD/CAM  technical  data  to  and  from  NAVSEA. 

•  All  offices,  shore  activities  and  detachments  under  the  command  of 
COMNAVSEA  shall  ensure  that  all  solicitations,  proposals  and  contracts  for  new 
construction,  conversion  modification,  modernization  and  overhaul  of  naval 
ships,  weapons  development  and  engineering,  design  services  and  other  new 
NAVSEA  acquisitions  incorporate  IGES  format  whenever  technical  data  are  to 
be  transferred  between  CAD/CAM  systems.  (Backfit  of  existing  acquisitions 
programs  is  encouraged  where  cost  effective  and  feasible.) 


The  second  policy  instruction  is  NAVSEA  Instruction  9085.3,  "Policy  for  Selected 
Record  Drawings  for  Ship  Acquisitions,"  dated  18  September  1984.  This  instruction 
requires  that  the  shipbuilder  deliver,  with  each  ship,  a  master  drawing  for  each  ship.  The 
master  drawing  shall  be  in  two  formats. 

-  Photo-Lithographic  plastic,  and 

-  Digitized  Initial  Graphics  Exchange  Specification-compatible  format 

The  Deputy  Commander  for  Nuclear  Propulsion  (SEA  08)  is  also  exempt  from  this 
requirement  so  long  as  the  intent  of  the  instruction  is  achieved. 


f.  Recommended  Implementation  Policy 

(1)  Development  Plan.  To  begin  the  implementation  process,  DoD  should 
issue  a  policy  for  fostering  CALS.  This  policy  must  tie  together  ongoing  and  planned  DoD 
logistics  support  efforts  and  create  an  integrated  roadmap  for  CALS  development, 
demonstration  and  phased  implementation.  In  general,  what  appears  to  be  needed  are 
means  to  attack  the  following  problems: 

(a)  A  lack  of  an  agreed-upon  conceptual  architecture  encompassing  a  DoD-wide 
system. 

(b)  A  lack  of  interfacing  rules  and/or  standards  that  would  allow  rapid 
intercommunication  between  diverse  systems. 

(c)  A  lack  of  priority  and  funding  for  pilot/demonstration  programs  which 
would  advance  the  overall  strategy  most  effectively. 

(2)  Recommended  CALS  Schedule.  (Refer  to  Figure  3.)  CALS 
implementation  should  be  a  progressive  process  beginning  with  specified  pilot  programs. 
Pilot  programs  would  demonstrate  conceptual  feasibility  and  could  be  used  to  examine  and 
adjust,  when  necessary,  the  overall  implementation  strategy.  This  building  block  approach 
would  permit  systematic  progress  reviews  and  serve  to  identify  system  changes  needed  to 
assure  reasonable  success  in  subsequent  implementation  phases.  Evaluation  of  pilot 
programs  would  identify  required  policy  refinements  and  lead  to  a  final  DoD  guidance  to  all 
Services. 


g.  Logistic  Support  Contract  Analysis 


Logistic  support  contract  requirements  imposed  on  four  typical  aerospace  programs 
were  analyzed  to  determine  if  changes  to  current  contracting  procedures  were  required  to 


implement  a  support  program  in  a  total  electronic  environment.  The  findings  of  the  contract 
analysis  are  summarized  as  follows: 


(1)  The  CDRL  DD  Form  1423  can  be  utilized  to  revise  the  delivery  media  from 
paper  to  electronic  form. 

(2)  A  technique  must  be  established  to  define  customer  reviews,  controllable 
audits,  and  acceptance  for  computerized  data. 

(3)  Computer  data  control  methods  must  be  established  to  control  working  data, 
proposed  data,  approved  data,  and  archival  storage. 

(4)  No  standard  exists  which  defines  electronic  transmission  media. 

(5)  The  training/publications  communities  must  revise  current  methods  to 
develop  and  conduct  support  services. 


As  we  transition  from  an  industrial  society  based  on  paper  to  an  information  society 
based  on  electronic  information,  we  will  use  the  computer  more  and  more  to  manipulate, 
manage,  and  store  our  information  needs  in  the  forms  of  text,  graphics,  images  and 
pictures.  The  requirements  for  the  information  may  not  change,  but  the  format  and  media 
will  change.  Therefore,  implementation  of  CALS  will  deal  with  software  data  rights  and 
electronic  data  bases.  A  review  of  possible  legal  issues  concerning  CALS  was  made 
through  the  Federal  Legal  Information  Through  Electronics  (FLITE)  system,  a  computer- 
assisted  legal  research  system  for  Federal  users.  The  review  did  not  highlight  any  legal 


Public  Law  96-511,  "The  Paperwork  Reduction  Act  of  1980,"  supports  the 
transition  from  paper  information  to  electronic  information.  One  of  the  purposes  of  the  law 


To  ensure  that  automatic  data  processing  and  telecommunications 
technologies  are  acquired  and  used  by  the  Federal  Government  in  a  manner 
which  improves  Service  delivery  and  program  management,  increases 
productivity,  reduces  waste  and  fraud,  and,  wherever  practicable  and 
appropriate,  reduces  the  information  processing  burden  for  the  Federal 
Government  and  for  persons  who  provide  information  to  the  Federal 
Government. 


However,  some  provisions  of  Public  Law  96-511  are  not  supportive  of  this  goal 
when  literally  interpreted  and  applied.  The  law  states  that  the  Director,  OMB,  is 
responsible  for: 

(1)  Reviewing  and  approving  information  collection  requests  proposed  by 
agencies; 

(2)  Determining  whether  the  collection  of  information  by  an  agency  is  necessary 
for  the  proper  performance  of  the  functions  of  the  agency,  including 
whether  the  information  will  have  practical  utility  for  the  agency; 

(3)  Ensuring  that  all  information  collection  requests: 

(a)  are  inventoried,  display  a  control  number  and,  when  appropriate,  an 
expiration  date; 

(b)  indicate  the  request  is  in  accordance  with  the  clearance  requirements  of 
section  3507;  and 

(c)  contain  a  statement  to  inform  the  person  receiving  the  request  why  the 
information  is  being  collected,  how  it  is  to  be  used,  and  whether 
responses  to  the  request  are  voluntary,  required  to  obtain  a  benefit,  or 
mandatory; 

(d)  are  disapproved  where  the  Director  determines  that  the  agency  has 
substantially  modified  in  the  final  rule  the  collection  of  information 
requirements  contained  in  the  proposed  rule  where  the  agency  has  not 
given  the  Director  the  information  required  in  paragraph  (1),  with 
respect  to  the  modified  collection  of  information  requirement,  at  least  60 
days  before  the  issuance  of  the  final  rule. 

A  legal  opinion  is  required  to  determine  what  impact  Public  Law  96-511  would 
have  on  CALS  implementation. 


c.  Supportive  Policy  Issuances 

(1)  Executive  12352.  Executive  Order  No.  12352,  "Federal  Procurement 
Reforms,"  supports  the  CALS  objectives: 

To  make  procurement  more  effective  in  support  of  mission  accomplishment, 
the  heads  of  executive  agencies  engaged  from  the  private  section 
shall:. ...Establish  programs. ...minimize  paperwork  burdens  imposed  on 
the  private  section. 

(2)  Federal  Acquisition  Regulation.  The  Federal  Acquisition  Regulation 
(FAR)  represents  the  Federal  Agencies'  implementation  of  public  laws.  One  particular 
section  of  the  FAR  which  supports  CALS  is  part  70  of  the  DoD  FAR  Supplement  on  the 
acquisition  of  computer  resources.  Part  70.4  of  the  DoD  FAR  Supplement  covers  the 
acquisition  of  Computer  Resources  under  10  USC  2315  Authority.  This  allows  the 
procurement  of  computer  resources  directly  without  General  Services  Administration 
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(GSA)  approval.  This  subpart  is  applicable  to  acquisition  of  automatic  data  processing 
equipment  or  services  if  the  function,  operation,  or  use  involves,  as  its  primary  purpose, 
one  of  the  following,  which  includes: 

Logistics  systems  which  provide  direct  support  to  operating  forces  or 
provide  support  to  maintenance  of  weapons  systems  (e.g.,  organic  supply, 
software  support  facilities  for  weapon  systems,  etc.).  This  does  not  include 
logistic  systems  supporting  contracting,  accounting,  disbursement  and 
budgeting,  etc. 

Determinations  as  to  the  applicability  of  this  subpart  shall  be  made  in  accordance  with  DoD 
component  procedures. 

(3)  DoD  Directive  4245.7,  Transition  From  Development  to 
Production.  This  directive,  dated  January  19,  1984,  authorizes  the  development  of  a 
manual  to  assist  acquisition  managers  in  the  execution  of  technically  sound  system 
development  programs.  Guidance  is  provided  by  identification,  assessment  and  reduction 
of  program  risk.  CAD,  CAM,  software  design  and  verification  are  program  areas  treated  in 
the  manual. 

(4)  The  Defense  Procurement  Reform  Act  of  1984.  This  act  requires  the 
Secretary  of  Defense  to  develop  a  plan  for  an  improved  system  for  the  management  of 
technical  data  and  a  plan  to  improve  the  Services'  computer  capabilities  to  store  and  access 
rapid  data  that  are  needed  for  the  efficient  procurement  of  supplies. 

2.  CALS  Data/Software  Ownership 

The  issue  of  software  rights  is  not  presently  covered  by  the  FAR.  Presently,  the 
void  is  filled  by  each  administrative  agency  issuing  its  own  clauses  and  regulations.  DoD 
has  covered  this  in  Part  27  of  the  DoD  FAR  Supplement  and  its  implementing  clause 
52.227-7013,  "Rights  in  Technical  Data  and  Computer  Software"  [formerly  DAR  7- 
104.9(a)].  These  regulations  set  out  the  rights  which  the  government  may  take  in  software 
within  these  two  boundaries: 

(1)  As  to  software  required  to  be  originated  or  developed  under  a  government 
contract,  the  government  takes  "unlimited  rights." 

(2)  As  to  software  developed  with  private  monies  or  commercial  computer 
software,  the  government  takes  "restricted  rights"  significantly  restricting  its 
use. 

The  DAR/DoD  FAR  Supplement  scheme  intends  to  balance  out  proprietary  rights 
and  the  needs  of  the  government,  and  has  been  relatively  successful  in  doing  so. 


However,  there  is  a  trend  to  attempt  to  erode  those  rights  by  current  legislation  and 
pressures  from  government  procurement  personnel.  Substantive  issues  include: 

(1)  Contractor  Proprietary  Rights  to  Software  Developed  Under 
IRAD  Funds.  While  the  government  does  contribute  to  IRAD,  the  entire  scheme  was 
developed  to  encourage  private  investment  by  permitting  the  contractor  to  retain  proprietary 
rights  (similar  to  the  patent  rights  retention  scheme).  However,  the  argument  is  still  being 
faced  by  contractors  from  those  in  government  wanting  to  procure  such  proprietary  items 
who  claim  that  they  should  take  ownership  to  those  rights.  Some  agencies  have  proffered 
the  argument  that  they  should  take  such  rights  in  view  of  their  portion  of  overhead  paid  on 
items  to  which  development  may  be  charged. 

(2)  Government  Monitoring  of  Rights.  There  is  some  question  in  the  minds 
of  contractors  as  to  the  ability  of  the  government  to  monitor  and  track  proprietary  software 
in  which  it  has  acquired  some  rights  to  use  for  limited  purposes.  Additionally,  the  DAR 
and  DoD  FAR  Supplement  encourages  the  government  to  acquire  only  those  rights  and  that 
software  necessary.  However,  contractors  have  recently  been  faced  with  more  requests  for 
acquisition  of  rights  in  software  without  a  predetermination  having  been  made  by  the 
government  buyers  as  to  what  is  needed.  This  has  even  occurred  on  R&D  efforts  in  which 
it  is  not  even  known  at  contact  inception  what  types  of  software  may  be  required. 

(3)  Confusion  About  Rights  Acquisition.  There  has  been  substantial 
confusion  as  to  rights  obtained  in  software.  While  software  documentation  delivered  under 
a  CDRL  becomes  the  government’s  in  one  sense,  even  if  the  software  is  provided  with 
unlimited  rights,  the  contractor  retains  intellectual  property  rights  therein,  including,  but  not 
limited  to,  the  right  to  license  usage  by  others.  However,  contractors  are  finding 
themselves  in  disputes  as  to  "ownership"  granted  by  the  various  levels  of  rights,  and, 
consequently,  wasting  time  and  resources  protecting  the  residual  rights. 

3.  Proprietary  Data  Rights  in  CALS 

In  general,  proprietary  data  do  nol  migrate  from  the  product  definition  data  base  in 
CAD/CAM  to  the  ILS  file.  The  prime  contractor/suppliers  do  not  incorporate  proprietary 
data  in  technical  manuals. 

Proprietary  data  are  used  to  develop  spare  parts  and  GSE  provisioning  data; 
however,  the  resultant  provisioning  data  merely  identify  part  numbers  and  general 
descriptions  of  the  parts  --  not  how  to  manufacture  the  part. 


Proprietary  data  will  not  reside  in  the  ILS  files  ~  they  will  be  in  the  CAD/CAM  file. 
The  real  issue  then  becomes  a  data  rights  issue  of  the  product  definition  in  CAD/CAM. 

Congress  is  attempting  to  legislate  certain  limitations  including  limits  on  the  time 
duration  for  proprietary  rights  and  suggesting  third  party  review  of  the  propriety  of  the 
rights. 

While  the  proprietary  data  rights  issue  is  identified  in  our  CALS  report,  it  should  be 
clearly  stated  that  it  is  no!  a  CALS  issue.  Proprietary  data  rights  is  a  CAD/CAM  issue, 
especially  when  we  visualize  government  access  to  contractors'  CAD/CAM  file.  The 
broader  issue  —  which  CALS  does  recognize  as  a  significant  technical  concern  —  is  CALS 
data  access  control.  This  issue  encompasses  proprietary  vs  non-proprietary  data,  classified 
vs  unclassified  data,  and  read/write  vs  read-only  permission.  Beyond  the  technical  aspects 
of  this  issue,  CALS  policy  must  recognize  that  there  will  be  limitations  on  data  access  for  a 
variety  of  legitimate  reasons,  and  that  these  limitations  must  be  an  explicit  design 
consideration  in  any  CALS  system  or  data  base. 

D.  INDUSTRY/GOVERNMENT  IMPACT 

1.  Changes  in  Acquisition  Process 

The  potential  benefits  of  CALS  implementation  will  be  realized  only  if  industry  and 
government  both  accept  the  attendant  changes  in  concept  and  methods  of  operation,  which 
the  paperless  weapon  system  and  paperless  logistics  system  will  necessitate.  The  structure 
of  the  weapon  system  acquisition  process  will  change  in  many  ways,  among  the  most 
fundamental  being: 

Logistics  influence  on  design, 

Acquisition  of  logistics  support  data, 

Competitive  acquisition. 

Data  audit/approval  techniques,  and 

Data  and  file  transfer. 

a.  Logistics  Influence  on  Design 


The  Logistic  Support  Analysis  (LSA)  process  begins  with  "design  to" 
supportability  requirements  levied  on  the  designer.  This  must  now  be  done  through  the 
CAD  system  so  that  the  designer  can  incorporate  the  required  supportability  features  during 


the  design  process.  Specific  supportability  design  rules  and  algorithms  must  be  included  in 
CAD. 


b.  Acquisition  of  Logistics  Support  Data 

Once  the  maintenance  plan  is  approved,  each  Government  Item  Manager  (spares, 
support  equipment,  technical  publications,  training  equipment,  etc.)  must  have  access  to  the 
defined  logistics  support  resources  resident  in  CALS.  With  appropriate  prior  approval,  use 
of  these  data  could  expedite  preparation  and  justification  of  purchase  requests. 
Additionally,  government  procurement  agencies  and  competition  advocates  could  use  the 
CALS  data  to  validate  the  purchase  order  and  reduce  procurement  processing  time. 
Methods  for  using  computer  data  to  expedite  approval  of  purchase  orders  must  be 
established  by  the  government.  Where  possible,  government  procurement  agencies  should 
have  the  capability  to  place  electronically  transmitted  contracts  with  the  true  manufacturer. 
Methods  for  receiving  and  processing  electronically  transmitted  government  orders  for 
logistics  support  must  be  established  by  industry. 


c.  Competitive  Acquisitions 

In  the  CALS  environment,  reprocurement  data  packages  as  they  are  known  today 
will  be  nonexistent.  The  data  will  reside  in  the  product  definition  data  file.  Government 
access  can  be  immediate  to  help  increase  competition  for  logistic  support  resources.  This 
can  eliminate  or  reduce  government's  cost  of  acquiring  and  maintaining  reprocurement  data 
packages.  The  reprocurement  data  file  will  also  simplify  government  transition  from  CFE 
to  GFE  during  the  production  cycle  after  system  maturity  and  design  stability  are  attained. 


d-  Data  Audit/Approval  Techniques 

As  paperless  logistics  support  becomes  available,  improved  data  auditing  and 
approval  techniques  must  be  developed.  Data  auditing  in  this  context  refers  to  assuring  that 
integrated  logistics  support  is  in  concert  with  the  approved  maintenance  plan.  This  auditing 
could  be  done  with  appropriate  edit  and  compare  programs.  The  approval  techniques  refer 
to  the  requirement  for  government  approval  of  the  maintenance  plan  upon  which  the 
support  system  is  built.  The  historical  process  of  delivering  multiple  copies  of  literally 
thousands  of  pieces  of  paper  for  review  and  mark-up  would  be  replaced  by  the  CALS 
continuous  flow  of  electronically  transmitted  data.  New  techniques  for  using  remote 


access/job  entry  terminals  with  on-line  update  capability  must  be  developed  to  support  these 
changes  in  methodology. 


e.  Data  and  File  Transfer 

At  some  point  in  time,  the  contractors'-developed  CALS  data  will  be  transferred  to 
a  government  agency(s).  Issues  to  be  addressed  here  are  the  method  of  transferring  (i.e., 
on-line  computer  vs  magnetic  tape,  etc.)  and  the  degree  of  software  standardization 
required.  In  the  long  term,  the  government  needs  to  define  their  logistics  data  base 
requirements  and  integrate  these  with  their  existing  automation  system.  In  the  near  term,  to 
capitalize  on  emerging  technology  DoD  should  recognize  that  the  prime  contractor's  data 
will  be  transferred  to  the  Logistic  System  Manager,  so  that  he/she  will  not  have  to  recreate  a 
weapon  system  file.  The  inventory  managers  (IMs)  can  operate  on-line  with  the  unique 
weapon  system  file.  When  the  government  ILS  Data  Bank  is  defined,  each  contractor  will 
format  his  data  for  direct  transfer  to  the  government  as  the  product  ends  its  production 
cycle. 

Additionally,  file-to-file  transfers  among  government  agencies  would  be  extremely 
beneficial  during  Program  Management  Responsibility  Transfer  (PMRT).  In  the  near  term, 
the  government  would  have  to  accept  selected  prime  contractor  data  using  common  data 
access  terminals.  For  the  long  term,  the  government  must  describe/develop  CALS 
standards  and  provide  for  updating  files  as  a  result  of  post-production  design  changes. 

2.  CantraslQr  Benefits 

Contractors  would  benefit  from  CALS  through  improved  logistics  support 
capability  and  increased  productivity.  Logistics  support  would  be  improved  by  accurate 
proration  recommendations  for  spares  modifications.  Status  of  repair  of  repairable 
components  at  vendor  facilities  would  be  available  to  prime  contractors  on  a  near-real-time 
basis.  Also,  CALS  offers  an  opportunity  for  automated  procedures  for  MILSTRIP 
requisitions  and  repair  parts  status  reporting  between  Interim  Contractor  Support  and 
government  agencies. 

Productivity  gains  would  be  significant.  CALS  data  would  be  input,  updated  and 
maintained  by  the  originator  of  logistics  support  information.  Access  by  all  users  would 
eliminate  the  need  for  redundant  files  and  significantly  reduce  the  effort  required  for  file 
maintenance.  The  potential  for  a  common  contractor/vendor  data  bank  could  create  further 
productivity  gains  by  reducing  CDRL  documentation  requirements.  Clearly,  government 
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and  industry  productivity  improvements  resulting  from  CALS  implementation  would  create 
engineering  and  logistics  support  efficiencies  that  would  result  in  cost  savings. 

3.  Government  Benefits 

CALs  would  provide  the  government’s  acquisition  and  logistics  agencies  with 
access  to  a  common,  single-source  logistics  data  base.  The  Program  Manager,  System 
Manager  (SM),  Deputy  Program  Manager,  Logistics  (DPML),  Resident  Integrated 
Logistics  Support  Agencies  (RILSA)  and  Item  Managers  would  have  engineering  and 
logistics  support  data  immediately  available  for  acquisition,  provisioning  and  procurement 
decisions.  Resident  Logistics  Support  Teams  and  Item  Managers,  including  DLA,  would 
share  common  data  that  could  be  used  for  rapid  agreement  on  provisioning  actions.  The 
DPML  and  SM  staffs  would  have  information  readily  available  to  coordinate  TCTO  kit 
requirements  for  simultaneous  modification  of  production  and  spare  components.  Current 
status  of  repairable  components  at  Interim  Contractor  Support  Facilities  would  permit 
expeditious  amendments  to  shipping  instruction  when  required. 

CALS  would  permit  logistics  support  considerations  beginning  with  the  conceptual 
phase  and  provide  the  government  with  early  access  to  both  design  descriptions  and 
logistics  planning.  Coupling  information  available  in  CAD  with  structured  logistics 
support  analyses  gives  an  added  dimension  for  producing  a  more  supportable  product. 
Improved  quality  and  supportability  would  result  in  increased  operational  readiness  and 
decreased  life-cycle  costs. 

4.  An  Illustration  of  CALS  Impact  on  Provisioning  and 

Supply— Activities 

The  application  of  current  and  evolving  computer  technology,  combined  with  the 
availability  of  CAD  and  CAM  data,  will  revolutionize  the  traditional  logistics  activities  of 
provisioning  and  supply.  DoD  provisioning  and  supply  activities  include  the  functions  of 
provisioning  technical  documentation  (PTD)  acquisition,  spare/repair  part 
procurement/reprocurement,  inventory  management,  storage  and  distribution. 
Provisioning  and  supply  activities  have  traditionally  been  expensive,  unwieldy  and  not 
particularly  responsive  to  the  needs  of  weapon  system  users,  managers  or  manufacturers. 
The  primary  obstacle  to  resolving  these  difficulties  has  been  the  impossibility  of  timely 
creation,  processing,  dissemination  and  update  of  the  mountains  of  data  that  are  associated 
with  DoD  provisioning  and  supply  activities.  With  the  advent  of  technologies  that  provide 
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inexpensive  data  storage,  improved  data  communication,  network-wide  operating  systems 
and  distributed  data  bases,  this  no  longer  needs  to  be  a  constraining  factor. 

The  application  of  existing  and  developing  computer  technology  to  DoD 
provisioning  and  supply  activities  will  significantly  alter  the  manner  in  which  these  are 
performed,  improve  their  cost  effectiveness,  and  make  them  more  responsive  to  the  needs 
of  weapon  system  users,  managers  and  manufacturers.  Although  the  means  of 
accomplishment  will  be  altered,  very  little  new  data  will  be  required.  Rather,  the  same  data 
that  are  currently  required  will  be  needed  in  a  different  format  or  on  different  media. 

In  the  provisioning  technical  documentation  arena,  the  application  of  these 
technologies  will  result  in  streamlining  and  standardizing  the  prepara  - 
tion/submittal/review/approval  process.  The  remaining  paper  flow  associated  with  PTD 
activities  will  be  replaced  with  exchanges  through  digital  media,  and  eventually  through 
direct  industry-to-DoD  system  communication.  At  the  same  time,  the  process  that  has  been 
initiated  with  the  development  of  MIL-STD-1388-2A  will  result  in  a  standard  industry-to- 
DoD  provisioning  data  format  for  all  DoD  components.  PTD  efforts  will  increasingly  be  an 
integral  part  of  the  LSA/LSAR  effort  and  will  make  extensive  use  of  CAD/CAM  parts  list 
data.  PTD  screening  activities  will  diminish  in  size  and  importance  as  data  on  parts 
presently  in  government  inventory  (Defense  Logistics  Supply  Center  data)  are  made  more 
readily  available  to  industry  and  are  integrated  with  CAE  and  CAD  parts  selection  and 
standardization  systems.  Traditional  illustrated  parts  breakdown  manuals  (IPBs)  and  repair 
parts  and  special  tools  lists  (RPSTLs)  will  be  replaced  with  on-line  computer  data  bases 
that  provide  DoD  personnel  with  all  necessary  data  concerning  appropriate  spare  and  repair 
parts. 

The  spare/repair  parts  procurement  function  will  also  undergo  significant  changes. 
The  present  manual  and  semi-automated  spares  delivery  tracking  systems  will  be  replaced 
with  on-line  systems  that  are  regularly  updated  with  information  from  industry  systems. 
These  updates  will  initially  be  performed  utilizing  data  that  are  transferred  via  removable 
computer  media.  Use  of  removable  media  for  data  transfer  will  eventually  be  phased  out 
and  replaced  with  direct  communication  between  DoD  and  industry  computer  systems.  The 
present  difficulties  encountered  with  acquisition  and  maintenance  of  reprocurement  data 
will  be  surmounted  through  implementation  of  a  variety  of  improved  capabilities  as  a  by¬ 
product  of  changes  that  are  occurring  in  several  other  areas.  Included  among  the  improved 
capabilities  are  automation  of  DoD  data  repositories  to  allow  improved  retrieval  of  existing 
engineering  data;  procurement  of  new  engineering  data  in  computer  sensible  formats  that 
are  more  accurate  and  easier  to  store,  retrieve  and  update  than  are  paper  media;  and 
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increased  use  of  contractor  data  and  personnel  to  facilitate  identification  of  acceptable 
substitute  and  lower  cost  replacement  items.  Benefits  will  also  accrue  from  changes  that 
are  occurring  in  the  parts  standardization  area  as  a  result  of  industry  movement  to  the  use  of 
CAE  and  CAD  systems.  Increased  use  of  standard  and  existing  inventory  parts  will 
decrease  the  volume  of  data  that  must  be  acquired  and  maintained,  while  the  movement  to 
CAE  and  CAD  systems  will  result  in  better  designs  that  have  fewer  unique  configurations 
and  that  require  fewer  retrofit  and  modification  actions.  The  present  "problem"  of  high  cost 
spares  and  support  equipment  will  disappear  as  weapon  system  designers  make  greater  use 
of  standard  parts,  DoD  systems  provide  improved  schedule  and  cost  visibility  to  system 
managers,  and  incentives  are  put  in  place  for  industry  to  design  systems  that  minimize  the 
need  for  expensive  and  unique  spare  parts. 

The  task  of  inventory  mangement  will  be  greatly  streamlined.  On-line  inventory 
management  systems  will  provide  improved  visibility  of  inventory  status,  consumption 
rates  and  locations.  These  systems  will  allow  DoD  personnel  to  spot  developing  support 
problems  and  initiate  resupply  and  procurement  actions  in  a  timely  manner.  Improved 
visibility  of  inventory  location  will  allow  system  managers  to  make  the  best  use  of  available 
assets  and  to  eliminate  the  problem  of  inadvertent  asset  disposal.  When  coupled  with 
improved  feedback  of  field  experience  data,  these  systems  will  allow  system  managers  to 
identify  high  payoff  areas  for  modification  and/or  redesign.  Weapon  system  users  and 
supply  activities  will  benefit  from  implementation  of  these  systems  by  being  able  to  quickly 
locate  needed  items  and  obtain  current  information  concerning  on-order  items. 

The  storage  and  distribution  function  will  also  change  as  a  result  of  the  application 
of  computer  technology.  Input  from  the  inventory  management  systems  and  feedback  from 
analysis  of  field  experience  data  will  allow  identification  of  such  storage  and  distribution 
problems  as  inadequate  quantity  allocations,  excessive  shipping  times  and  excessive 
shipping  costs.  In  the  same  way,  inventory  will  be  reduced  through  timely  identification 
and  disposal  of  unneeded  items  and  more  effective  management  of  calibrated  and  limited 
life  components. 
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AIR  STAFF  INITIATIVE  TO  DEVELOP  A  STANDARD  FOR  A 
DELIVERABLE  DATA  BASE  SYSTEM 


Our  interest  in  this  subject  continues  to  grow  as 
realizations  of  paperless  systems  evolve.  At  Air  Staff  our 
responsibilities  center  on  the  integration  of  management  policy 
specifically  for  acquisition,  program  management  direction, 
systems  engineering,  and  embedded  computers.  Most  recently  we 
have  been  tasked  with  logistics  R&D,  acquisition  logistics  and  the 
departmental  standardization  office.  Our  place  is  full  and 
varied,  but  this  is  not  totally  detrimental.  Like  most  Air  Force 
offices  we  could  do  more  with  more  people,  but  then  we  would  lack 
cross  fertilization  that  allows  our  small  staff  to  gain  insight 
into  developing  trends  and  new  ideas.  One  of  these  new  ideas  is 
the  proposed  standard  for  a  deliverable  data  base  system.  The 
idea  is  one  way  to  assure  that  the  Air  Force  receives  adequate 
engineering  data  to  allow  the  competitive  procurement  of  spare 
parts,  which  brings  us  to  the  origin  of  the  idea; 

The  1983  AFMAG  i nvest igat i ng  the  competitive  procurement  of 
spare  parts  was  keenly  interested  in  the  causes  for  our  inability 
to  buy  spare  parts  competitively.  To  expedite  the  investigation 
of  these  causes,  the  AFMAG  was  divided  into  two  groups:  a 
requirements  group  and  an  execution  group.  These  groups  were 
subdivided  into  panels:  the  data  management  panel  concentrated 
on  the  question,  "why  don't  we  have  the  data  in  hand  to  complete 
the  acquisition  of  spare  parts?"  Their  investigation  examined 
the  procedures  used  for  buying  engineering  drawings  and 
associated  lists  to  stock  an  Air  Force  assembled  data  base,  the 
contractor's  method  of  drawing  preparation,  and  the  Air  Force's 
way  of  reviewing  and  accepting  contractor  prepared  data.  They 
found  the  procedures  contained  many  stumbling  blocks. 

o  DoD  directives  require  the  acquisition  of  drawings  and 
associated  lists  as  data. 


o 


Contractor  prepared  drawings  are  not  subjected  to  an 
actual  deraonstrat ion  for  future  uses. 

o  General  lack  of  logistics  considerations. 

o  Provisioning  is  done  too  early;  in  too  short  a  time. 

o  Drawing  storage  and  transmission  techniques  are 
outmoded . 

DoD  directives  force  the  Services  to  buy  engineering 
drawings  and  associated  lists  in  the  same  manner  as  short  term 
management  data.  They  require  the  Services  to  tailor 
specifications,  standards  and  data  item  descriptions  to  match  the 
current  acquisition,  paying  little  regard  to  future  needs.  This 
practice  is  perpetuated  by  the  Data  Requirements  Review  Board 
that  scrubs  data  requirements  to  reduce  the  amount  of  data 
procured--a  temporary  expedient  that  can  often  eliminate  data 
needed  for  breakout/competition.  Contractor-prepared  drawings 
are  never  subjected  to  an  audit  that  would  vigorously  demonstrate 
their  capability  to  support  breakout,  competitive  acquisition  or 
to  justify  proprietary  rights  claims.  The  physical  configuration 
audit  is  our  last  look  at  drawings  before  delivery.  This  audit 
checks  to  see  that  the  drawings  depict  the  item  produced,  not 
that  the  drawings  can  be  used  to  produce  the  item. 

Post  production  support  or  interim  contractor  support  may  be 
planned  for  early  on  in  the  acquisition  process,  but  the 
specifications,  standards  and  data  item  descriptions  used  to  buy 
drawings  are  not  conducive  to  producing  a  data  system  to  support 
post  production  support  by  a  contractor  other  than  the  prime. 
Interim  contractor  support  is  usually  applied  as  a  catch-up  sole 
source  contract.  Provisioning  exercises  are  forced  and  occur  too 
early  under  unfavorable  circumstances  --  normally  with 
insufficient  or  incomplete  drawings.  Acquisition  (procurement) 
method  coding  is  often  performed  by  personnel  who  have  little 
knowledge  about  the  items  being  coded  and  usually  under 
exceedingly  short  time  constraints.  Drawings  are  required  to  be 
delivered  to  outmoded  standards,  microfilm  on  aperature  cards. 


Microfilm  technology  requires  strigent  drawing  room  practices 
that  are  no  longer  in  use  by  major  contractors.  Microfilm  is 
subject  to  physical  damage  and  loss  (the  latest  Air  Force  audit 
reported  that  10?  of  those  cards  removed  from  files  never  find 
their  way  back,  and  20?  of  the  cards  have  illegible  content). 
Repository  equipment  is  outdated  and  AFLC  has  been  informed  by 
the  servicing  contractor  that  he  will  no  longer  service  some 
equipment.  A  number  of  good  initiatives  are  in  work  now  to 
correct  these  stumbling  blocks. 

Present  DoD  policies  and  procedures  tend  to: 

o  Freeze  copies  of  the  evolving  drawings,  cut  the  copies 
off  from  the  parent  data  base,  and  use  the  documents  in 
isolation. 

o  Encourage  the  buying  of  insufficient  and  obsolete 
drawings . 

o  Force  the  services  to  contrive  a  permanent  data  base 
piecemeal . 

o  Prevent  services  from  achieving  self  sufficiency. 

o  Have  the  contractor  prepare  drawings  to  match  his 

internal  needs  without  considering  the  future  needs  of 
the  Air  Force. 

Data  management  panel  discussions  on  how  to  overcome  these 
stumbling  blocks  led  to  the  realization  that  for  years  we  have 
been  trying  to  assemble  effective  Air  Force  data  base  systems  for 
weapon  systems,  without  success.  In  short,  the  panel  concluded 
that  the  piecemeal  assembly  of  a  multi-purpose  data  base  from  a 
weapon  system,  subsystem  or  equipment  acquisition  was  impossible 
under  present  data  acquisition  policies.  Yet  we  desperately  need 
to  have  these  data  bases.  Service-owned  data  bases  are  essential 
for  the  life  cycle  support  of  fielded  systems  or  equipment.  They 
provide  the  Service  some  element  of  independence  from  their  prime 
and  vendor  contractors.  They  also  allow  the  making  of 


independent  decisions.  But  for  all  our  special  management 
interest  shown  in  the  past,  we  remain  dependent  on  the 
contractor’s  data  base  to  provide  the  support  needed. 

So  the  Panel’s  question  eventually  came  down  to  ’’why  don't 
we  tell  the  contractor  what  we  want  a  data  base  to  do,  then  turn 
to  him  loose  and  let  him  develop  the  data  base  system."  The 
panel  reasoned  that  the  Air  Force  needs  to  stop  thinking  of 
engineering  drawings  and  associated  lists  in  terms  of  paper 
products  and  open  the  door  to  the  Services’  conversion  to 
automated  technical  information  systems.  Instead  of  adding 
patches  to  our  already  old  and  leaky  data  handling  system,  we 
should  write  a  new  comprehensive  standard  for  a  deliverable  Air 
Force  data  base  system.  Then,  place  the  requirement  for  the 
development  of  a  data  base  system  in  the  contract  as  a  line  item 
deliverable  just  as  we  do  for  the  system,  equipment  or  software. 

The  new  standard  would  require  the  contractor  to  develop  or 
assemble  a  data  base  that  does  all  the  functions  that  the 
contractor's  data  base  normally  does,  as  well  as  those  functions 
that  enhance  future  management  of  the  program.  He  would  be 
required  to  consider  upfront  in  design  the  issues  of  breakout, 
provisioning,  acquisition  data  package  identification, 
acquisition  method  coding,  and  competitive  acquisition  of  spare 
parts.  The  standard  would  contain  requirements  to  develop  and 
build  a  functioning  data  system  that  could  be  demonstrated, 
tested  and  audited.  Thus  we  would  be  assured  of  sufficient 
technical  data  to  manage  the  system/item  throughout  its  life 
cycle . 

Buying  an  Air  Force  data  base  system  as  a  contract  line  item 
has  several  benefits: 

o  Unify  commands  requirements, 

o  Provide  in  management  alternatives, 

o  Allow  phased  modernization  of  techniques, 

o  Program  management  responsibility  transfer  asset. 
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An  Air  Force  data  base  system  would  have  other  benefits:  It 
could  serve  as  a  precontract  agreement  between  the  implementing 
and  the  supporting  commands;  become  that  single  tailored  standard 
to  show  a  united  Air  Force  to  the  contractor;  place  it  on 
contract  as  a  line  item,  removing  it  from  the  normal  data 
requirements  review  process;  and  it  would  no  longer  be  subjected 
to  data  requirements  review  board  scrub  or  program  cuts. 

Also,  having  a  deliverable  data  base  system  would  place  the 
Air  Force  in  a  very  flexible  position.  We  could  choose  to 
contract  with  the  prime  to  maintain  the  system  of  a  post¬ 
production  support-type  contract  and  deliver  hard  copy  to 
selected  Air  Force  offices  as  needed;  contract  with  the  prime  to 
set  up  and  maintain  satellite  data  terminals  at  air  logistics 
centers,  operational  units,  or  other  locations;  take  delivery  of 
the  system  and  integrate  it  into  the  depot's  system,  or, 
depending  on  the  size  or  application,  take  delivery  of  the  system 
and  turn  it  over  to  an  operational  unit  or  other  custodian  for 
management  and  upkeep. 

Yet  another  advantage  to  having  the  contractor  develop  and 
build  a  deliverable  data  base  is  that  the  contractor  can  be 
encouraged  to  use  the  most  modern  techniques  for  data  storage  and 
transmission.  In  his  article,  Senior  Executives  After  Reform  88, 
Mr.  Reynolds  observed  that  PL  96-511  may  be  called  "The  Paperwork 
Reduction  Act  of  1980,"  but  it  deals  mostly  with  paper's 
replacement  —  computers.  Our  data  repositories  are  geared  to 
paper  copy  type  storage  and  retrieval.  Edcars  will  certainly 
help  automate  the  old  paper  techniques,  but  we  need  to  phase  in 
modern  computer  aided  information  systems.  We  think  the  standard 
will  make  this  happen.  Finally,  a  deliverable  data  base  system 
would  also  provide  a  tangible  asset  to  transfer  from  the 
implementing  command  to  the  supporting  command  at  the  time  of 
program  management  responsibility  transfer.  Transfer  of 
ownership  of  the  data  system  would  truly  represent  a  total  shift 


in  responsibility,  because  the  supporting  command  would  take 
possession,  at  least  contractually,  of  the  data  base  that 
controls  the  configuration  of  the  weapon  system. 

The  data  management  panel  toyed  with  this  idea  for  several 
weeks  and  considered  it  worthy  enough  to  prepare  a  draft 
standard.  Their  standard  includes  those  functions  that  the  data 
base  must  perform.  It  is  a  rough  draft  that  was  assembled  by 
taking  excerpts  from  the  various  standards  that  cover  the 
system's  acquisition  life  cycle.  It  simply  shifts  some  of  the 
responsibilities  of  the  government  to  the  contractor.  Now  he 
must  develop  a  data  base  system,  and  we  can  inspect,  test,  audit 
and,  yes,  even  reward  his  efforts  based  on  the  requirements  set 
forth  in  the  standard.  Unfortunately,  the  AFMAG,  while  still 
supportive  of  the  idea,  realized  that  it  could  take  time  to 
nurture  and  sell  the  idea  to  the  established  data  management 
community  and  offices  that  govern  the  acquisition  of  data.  Also, 
before  the  panel  could  proceed  with  a  radical  departure  from  the 
established  information  management  system  they  would  have  to 
obtain  permission  from  the  Office  of  the  Secretary  of  Defense. 
Since  the  AFMAG  did  not  have  sufficient  time  to  generate  the 
support  for  the  standard  or  pursue  its  approval,  they  chose  to 
work  within  the  existing  data  management  system  and  to  recommend 
improvements  to  areas  that  would  enhance  the  assembly  of  a  viable 
data  base.  These  recommendations  are  now  being  integrated  into 
the  various  regulations,  specifications  and  standards  that  are 
used  to  acquire  data.  Air  staff  believes  the  idea  has  potential, 
especially  as  an  instrument  to  break  away  from  a  paper  product 
world  and  convert  to  automated  technical  information  systems. 
Therefore  we  have  picked  up  the  idea  and  are  actively  soliciting 
support  for  the  idea. 
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•  A  DOCUMENT  PREPARED  SPECIFICALLY  TO  SUPPORT  ACQUISITION 

STANDARD: 

•  A  DOCUMENT  THAT  ESTABLISHES  ENGINEERING  AND  TECHNICAL 
REQUIREMENTS  FOR  SELECTION,  APPLICATION  AND  DESIGN 
CRITERIA  FOR  MATERIEL. 

ADVANTAGE^: 

•  MAJORITY  OF  STANDARDS  ARE  VOLUNTARY. 

•  THEY  IMPROVE  OPPORTUNITIES  FOR  TECHNICAL  PROGRESS. 

•  THEY  INCREASE  ORDER/REDUCE  PROLIFERATION. 

•  LOWER  LIFE-CYCLE  COSTS. 

MISCONCEPTIONS: 

f  TEND  TO  REDUCE  COMPETITION. 

•  TEND  TO  RESTRICT  USING  LATEST  TECHNOLOGIES. 


•  ARE  OFTEN  TOO  RESTRICTIVE. 
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POLICY/LEGAL  CONSTRAINTS  SUBGROUP  ACTION  PLAN 


1.  Scope  and  subgroups  task  and  task  assignments. 

A.  Legal  Issues  -  Burt  Newlin 

o  Examine  Current  Laws/Regulations/Constraints 
o  Examine  Product  Rights/Product  Integrity/Product  Liability 

a.  Burt  Newlin  will  collect  pertinent  laws  and  regulations  and  categorize  the 
constraints. 

b.  He  will  then  task  subgroup  members  to  assist  in  analyzing  specific 
regulations,  laws,  specifications  and  standards  to  develop  recommended  changes. 
Item  I.A.a.  will  be  completed  by  next  meeting. 

B.  Policy  Issues  -  All  Members 

o  Research  Requirements/Standards/Timing/Conf iguration 
Management/Gov’t  Audit/T ransmission. 

The  whole  group  will  address  Policy  Issues.  The  initial  brainstorming  session  has 
identified  potential  issues  which  will  be  refined  and  sent  to  the  CALS  committee. 
Our  objective  is  to  guide  other  subgroups  to  assure  that  they  address  all  of  the 
policy  issues  in  the  context  of  their  individual  charters.  Howard  Chambers  will 
handle  integration  of  subgroup  inputs. 

C.  Implementation  Roadmap 

o  Examine  DoD  instruc:ions/DAR-FAR/Contracting 
o  Evaluate  Pilot  Program s/Options/Conversion/ .Media  by  program 
pnase/(take  user-need  approach) 

a.  \e:i  Christianson  will  lead  this  activity  using  the  same  approach  outlined 

in  l.A  above. 

2.  Mat'ix  Oversea. 

It  was  agreed  that  a  policy  matrix  will  be  prepared  to  scope  the  logistics 
support  activities  (both  design-to  and  support)  as  they  relate  to  the  major  policy 
areas.  Howard  Chambers  will  prepare  this  strawman  matrix.  This  matrix  will  be 
available  to  policy  subgroup  members  within  one  week.  This  matrix  will  help  us 
focus  on  the  real  issues. 


POLICY  AND  LEGAL  CONSTRAINTS  SUBGROUP 


Subgroup  Members 


CALS  Poiicy  and  Legal  Subgroup 


June  12,  1984 


POLICY  LEGAL  CONSTRAINTS  SUBGROUP 


Notes  on  12  July  84  Meeting 


l.  Scope  and  subgroups  task  and  task  assignments. 


A.  Legal  Issues 

o  Current  Laws/Regulations/Constraints 
o  Product  Rights/Product  Integrity/Productability 

(Burt  Newlin  will  collect  pertinent  laws  and  regulations  and  categorize  the 
constraints.) 


B.  Policy  Issues 

o  Requirements/Timing/Configuration  Management/Gov't  Audit 
(The  whole  group  will  address  Policy  Issues  -  see  below) 

C.  Implementation  Roadmap 

o  DoD  Instructions/DAR-FAR/Contracting 

Pilot  programs/options/conversion/(take  user-need  approach) 


2.  Matrix  Overview 

It  was  agreed  that  a  matrix  presentation  that  would  scope  the  logistics 
support  data  proved  to  be  useful.  (Howard  Chambers  will  provide  his  view  of  such 
a  matrix.) 


3.  A  group  discussion  of  policy  issues  was  held  which  resulted  in  the  following 
unstructured  list  of  candidate  policies  and  questions: 

(i)  Policy  to  motivate  contractors  to  develop  support  data  as  part  of  their 
CAD/CAE  data  base  homework. 

(ii)  Policy  to  deal  matrix  digital  data  format/ delivery  defintion  to  replace 
paper  world  definitions  in  our  current  contractive  procedures. 

-  requires  that  the  government  is  able  to  receive  digital  data 

-  may  restrict  flexibility  of  current  system 

-  may  create  problems  with  small  contractors 
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(iii)  Policy  to  deal  neither  the  proliferation  of  many  different  types  of 
computer  hardware  and  software  in  use  in  DoD  business  in  order  to  contain 
interfacimg  problems. 

(iv)  Policy  to  have  contractors  develop  digital  data  bases  which  would  meet 
stated  needs  rather  than  specifying  exact  data  packages  for  delivery. 

-  Software  can  now  be  bought;  why  not  extend  this  to  engineering  data, 
maintenance  data,  etc. 

-  current  system  does  not  allow  buying  such  data  or  even  having 
contractor  maintain  it  for  DoD  use. 

-  currently  a  spec  or  a  standard  is  the  only  basis  for  specifying  data 
delivery. 

(v)  Is  there  a  policy  for  CAD/CAM  which  could  be  used  as  a  model  for 
CALS? 

(vi)  Must  insure  that  any  CALS  policy  does  not  constrain  CAD/CAM 
architecture. 

-  want  to  be  able  to  feed  back  lessons  learned 

-  CALS  data  must  be  available  from  CAD/CAM  data  base  but  don't 
constrain  early  phases  of  design  by  CALS  policy. 

(vii)  Policy  regarding  responsibility  for  CALs  maintenance  throughout  the 
life  cycle  of  the  system. 

(viii)  Policy  to  define  the  scope  and  definition  of  CALS. 

-  is  CALS  an  entity  or  is  it  an  indistinguishable  part  of  the  process  of 
digitizing  the  whole  acquisition  and  support  process. 

-  what  is  the  content  of  CALS  either  separately  or  as  part  of  the 
greater  entity. 

(ix)  All  CAD/CAM/CALS  policies  must  pass  the  filter  of  technology 
transparency 

-the  intent  of  policicies  for  computer-aided  systems  is  to  utilize  new 
technology  not  to  impede  future  technology  changes. 

(x)  Policy  must  be  flexible  enough  to  handle  large  and  small  contractors, 
included. 

-  above  this  level  options  should  be  available  to  handle  intermediate 
levels  of  complexity 


(xi)  Policy  must  be  established  to  handle  the  process  of  conversion  to  digital 
data  and  unified  data  bases. 

-  driving  conversion  both  tapes  and  drawings  may  be  required 

-  people  msut  be  trained  to  use  digital  data 

-  conversion  generally  involves  increased  cost  and  reduced  efficiency. 

It  must  be  planned  as  to  timing  and  cost. 

(xiii)  Policy  regarding  access  to  digital  data  is  needed  rather  than  delivered 
data  packages  which  are  often  overspecified. 
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THOUGHTS  ON  THE  FIRST  MEETING  OF  CALS  GROUP 


Emerson  D.  Cale 


Department  of  the  Navy 


June  29,  1984 


DEPARTMENT  OF  THE  NAVY 

OFFICE  OF  THE  CHIEF  OF  NAVAL  OPERATIONS 
WASHINGTON.  OC  20350 
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29  June  1984 


Mr.  Richard  Gunkel 
Institute  for  Defense  Analyses 
1301  Beauregard  Street 
Alexandria,  VA  22311 

Dear  Mr.  Gunkel, 

I  want  to  pass  along  some  thoughts  on  the  first  meeting  of 
CALS . 

Prom  the  first  meeting  it  was  clear  that  there  is  a  firm 
commitment  by  each  of  the  Services  to  implement  specific  aspects 
of  automation  of  Technical  Information  (TI).  If  I  heard 
correctly,  all  three  Services  have  established  project  offices, 
committed  money,  and  people  to  do  several  things.  Specifically, 
they  are  all  committed  to  converting  drawing  repositories  by 
scanning  and  digitizing  existing  drawings  and  are  looking  to 
receiving  drawings  and  associated  data  from  contractors  in 
electronic  form.  Army  and  Air  Force  have  a  joint  contract  to  do 
so.  Navy  s  in  an  earlier  stage  but  will  begin  conversion  in 
about  two  years. 

Secondly,  all  three  are  committed  to  bringing  in  hardware 
systems  to  allow  presentation  of  technical  information  directly 
to  maintenance  personnel  in  lieu  of  paper  manuals.  Third,  there 
is  a  move  to  computer  based  learning  in  the  Services  school 
houses.  It  would  appear  to  be  advantageous  to  have  a  stream  in 
the  overall  architecture  or  strategy  which  is  a  kind  of  road  map 
and  or  time  line  along  which  the  technical  and  contractual 
issues  can  focus  on  meeting  these  objectives.  As  a  structure,  I 
suggest  the  idea  of  a  set  of  categories  be  identified  for  which 
a  road  map  can  be  laid  out.  The  categories  should  be  organized 
in  a  way  which  will  be  recognizable  and  comfortable  to 
government  and  contractors.  Perhaps  a  variation  of  the 
traditional  logistics  elements;  i.e.,  maintenance,  supply,  test 
equipment,  training,  etc.,  and  a  functional  expression.  All 
data  and  data  products  are  acquired  from  contrr  "tors  to  perform 
a  function.  We  differ,  in  the  Services,  as  to  the  tasks  applied 
to  the  function  but  not  in  the  function.  For  example,  drawings 
are  acquired  for  serveral  functions;  i.e.,  perform  maintenance, 
reprocurement,  configuration  control.  Perhaps  we  could  get 
agreement  of  categories  for  the  framework  upon  which  the  issues 
and  problems  can  be  identified,  tracked  and  pursued. 

Another  point,  I  think  we  could  use  a  vehicle  to  record 
agreed  upon  decisions,  assumptions  and  constraints.  I  think 
overyone  will  begin  to  be  more  comfortable  and  can  focus  better 
when  we  see  the  choices  and  the  ambiguity  begin  to  narrow.  At 
first  it  could  just  be  a  compendium  of  stated  positions, 
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assumptions  and  decisions  which  would  later  be  integrated  as 
part  of  the  strategy  wherever  they  may  fit.  We  could  start  with 
some  easy  ones  to  build  on.  Some  very  specific  and  some  broad 
statements  of  intent  or  strategy.  For  example,  I  detected  some 
conce  n  by  industry  as  to  the  intention  of  the  homework  question 
on  CAD  systems.  I  think  a  statement  regarding  the  sanctity  of 
proprietary  procedures,  systems,  and  techniques  in  the  pursuit 
of  the  overall  goals  would  help  and  set  bounds  that  will  assist 
in  getting  industry  cooperation.  A  broad  statement  of  intent  to 
"pursue  standardization  on  data  elements  and  interface  rather 
than  hardware  or  contractor  systems"  might  be  useful. 

Obviously,  the  homework  propositions  2,  3,  and  4  are  the  type  we 
should  document. 

The  enclosed  study  looked  into  the  uncoordinated  introduc¬ 
tion  of  automation.  It  has  some  interesting  comparisons  and  a 
tabulation  of  known  uncoordinated  proliferation  of  hardware  and 
systems.  It  may  be  of  some  use. 


Respectfully, 

/ 

A)  •  (_C. 

EMERSON  D.  CALE 


Enclosure 
(As  stated) 


STANDARD  TO  ACQUIRE  TECHNICAL  INFORMATION  IN 
DIGITAL  FORM  AND  CALS  DEMO  ACTION 


Emerson  D.  Cale,  S.  C.  Rainey 


Chief  of  Naval  Operations 


September  26, 1984 


DEPARTMENT  OF  THE  NAVY 

OFFICE  OF  THE  CHIEF  OF  NAVAL  OPERATIONS 
WASHINGTON.  DC  20350 


i*  «*rri  r  mrrcm  to 

26  September  1984 


Institute  for  Defense  Analysis 
Attn:  Dr.  Fred  Riddell 

1801  North  Beauregard  Street 
Alexandria,  VA  22311 

Fred, 


Just  thought  I  would  share  the  enclosed  NTIPP  memo  with  you. 
It  describes  the  Navy  level  of  understanding  of  current  technol¬ 
ogy  as  we  try  to  automate  technical  manuals.  Sam  Rainey  is  pre¬ 
paring  a  Navy  plan  for  implementation  of  this  automation  for  me 
right  now.  I  should  have  it  next  week  and  will  share  it  with 
you.  We  are  planning  three  tests  of  this  technology  in  1985.  I 
have  given  these  to  Tom  Bahan  as  candidates  for  demonstration 
for  CALS.  They  are  a  F-14  control  system  to  be  demonstrated  in 
the  spring  of  85  and  a  shipboard  radar  repeater  in  the  summer. 

The  third  is  the  DDG-51  which  is  longer  term  and  will  get  going 
in  a  year.  The  85  demonstrations  are  a  side-by-side  comparison 
of  hands  on  maintenance  performed  using  old  MIL-SPEC  type  paper 
manuals  and  a  totally  new,  electronically  authored,  approach 
using  a  CRT  to  direct  the  maintenance  steps. 

The  Navy  owns  the  authoring  system  (hardware)  which  has  been 
used.  It  has  built  in  software  to  allow  presentation  format  in 
microform,  paper,  or  CRT  by  flick  of  a  switch. 

Incidently,  Sam  Rainey  is  compiling  the  Navy  program 
descriptions  you  had  asked  for  in  the  three  Service  matrix. 

I  will  be  away  until  22  October  but  can  be  reached  at  home 
on  weekends.  Home  address  is  4427  Majestic  Lane,  Fairfax,  VA 
22033;  home  phone  is  378-6009. 

Sincerely, 

EMERSON  D.  CALE 


Enclosure 
(As  stated) 


9  September  1983 
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MEMORANDUM 

Fran:  S.  C.  Rainey 
lb:  NTIPP  File 

Subj:  Standardization  of  Specifications  for  Acquisition  of  Technical 
Information  in  Digital/Electronic  Form 

1.  It  has  been  demonstrated  (by  NTIPP,  among  others)  that  Technical  Information,  ( 
text  and  graphics,  can  be  prepared  in  the  form  of  a  digital  data  stream  (an 
"electronic  galley")  which  contains  suitable  embedded  generic  coding  so  that 

the  TI  can  be  later  mastered  for  optimal  replication  in  any  of  several  media, 

A  highly  reliable  non-volatile  transportable  median  is  needed  (for  exarple,  a  * 
digital  optical  disc)  as  well  as  a  display  median  (e.g.,  a  plasma  panel,  electro- 
lonine scent  panel,  or  if  these  both  fail  to  prove  out,  a  cathode  ray  tube).  For 
cases  where  it  is  impractical  (or  uneconomical)  to  generate  the  TI  directly  in 
digital/electronic  form,  a  scanner  and  raster-to-vector  software  can  correct  the 
material  to  digital/electronic  form  with  the  same  results  (assoning  scanner 
technology  picks  up  a  little) . 

2.  But  without  seme  control  from  the  TI  customer  (the  various  Services  of  the 
DoD  primarily) ,  a  nearly  infinite  nonber  of  approaches  to  acoonplishing  such  a 
result  could  arise:  with  (hundreds  of  different  kinds  of  oonputers)  X  (thousands 
of  different  kinds  of  software  approaches)  X  (dozens  of  different  kinds  of  generic 
coding) .  in  general,  then,  a  Specification  is  needed,  telling  not  only  what  is 
required,  but  delineating  all  the  requirements  of  the  signal  characteristics: 
input/output,  embedded  coding,  programming,  and  language.  Such  a  specification 
would  require  coordination:  (1)  among  the  Army,  Navy,  and  Air  Force;  (2)  with 
industry  associations  (e.g.,  NSIA,  AIA,  GCA,  and  others);  (3)  with  standards 
associations  (IEEE,  ISO,  1©S,  etc.).  Then  not  only  must  a  specification 

ensure  that  a  usable  product  is  provided,  it  must  also  ensure  that  a  single 
type  of  product  is  received,  to  permit  pooling  of  DoD  archives  and  other  TI 
data  bases,  corrmon  configuration  management  of  TI,  and  uniform  TI  update  and 
correction  procedures.  Automation  technology  will  undoubtedly  be  required  to 
enhance  currently  defined  types  of  TI,  drawings,  test  data,  arri  many  other 
kinds  of  information  as  yet  unthought  of. 

3.  Another  tool  will  be  required:  an  inspection  program  or  an  extensive 
software  system  so  that  a  contractor's  output  can  be  tested  for  carpi iance 
with  the  specification  cited  above.  Thus  in  addition  to  the  necessity  for  the 
DoD  to  maintain  (together  with  others)  a  Specification  or  Standard  to  accomplish 
the  purpose  of  defining  the  required  product,  it  also  would  have  to  maintain 
software  and  the  aorputer  facility  to  exercise  it  on,  to  make  sure  that  the 
incoming  TI  meets  the  requirements. 


4.  It  appears  to  me,  however,  that  what  the  DoD  does  not  need  to  maintain,  or 
to  provide  to  contractors,  is  the  automated  authoring  program  by  thich  the 
digital/electronic  TI  is  actually  generated.  Issue  the  specification  describing 


the  requirements  in  detail,  and  let  industry  use  whatever  programs  and  whatever 
mainframes  they  find  most  practical  to  meet  these  requirements.  Any  Government- 
issued  authoring  program  for  this  purpose  would  have  the  following  disadvantages: 

a.  It  would  be  expensive.  It  would  require  a  staff  of  civil  servants  to 
keep  the  program  up  and  running  (and  modify  it  as  the  occasion  arose) . 

b.  It  would  limit  ocnpetiticn.  No  matter  how  broadly  applicable  such  a 
program  was  written,  there  would  still  be  many  perfectly  good  computers 
aid  operating  systems  that  couldn't  use  it  without  extensive  modification. 

c.  It  would  lay  the  burden  of  meeting  the  requirements  mainly  on  the  Government 
and  to  a  lesser  extent  on  the  contractor.  If  the  Government's  author¬ 
ing  program  were  used  by  a  contractor  (provided  as  GFE)  to  generate  TI, 

how  can  the  contractor  be  held  responsible  for  a  case  vhere  the  TI 
fails  to  meet  specifications? 

5.  If,  on  the  other  hand,  industry  is  permitted  (required)  to  develop  its  own 
authoring  programs,  three  classes  of  oorpanies  will  emerge: 

a.  Those  large  enough  to  automate  the  production  of  their  own  TI  (many 
already  have)  in  such  a  way  as  to  meet  specifications. 

b.  Software  houses  who  already  provide  TI  services  to  a  host  of  customers 
who  do  not  prepare  their  own  TI  will  tool  up  to  provide  this  kind  of 
automation  on  a  wide  basis  to  customers  who  are  DoD  contractors. 

c.  Snail  companies  (mem  and  pop  shops)  who  now  make  commercial  and  near- 
commercial  manuals,  will  buy  their  digital/electronic  TI  preparation 
from  the  software  houses  above,  just  as  they  buy  other  specialized 
services  from  specialized  contractors  (with  the  cost,  as  usual,  passed 
on  to  the  Government) . 

6.  Much  can  be  learned  from  the  Navy's  experience  with  the  TRUMP  (Technical 
Review  and  Update  of  Manuals  and  Publications)  Facility  at  the  Naval  Air  Rework 
Facility,  Jacksonville,  Florida.  Completed  in  the  1970 's,  this  highly  automated 
in-house  facility  functioned  successfully  for  almost  a  decade  to  update  out-of¬ 
production  aircraft  manuals.  Vhen  it  was  changed  to  GOCO  status  (Government- 
Owned,  Contractor-Operated) ,  costs  dropped  but  efficiency  remained  about  the 
same.  Now  the  Navy  has  made  the  decision  to  rely  entirely  on  contractors  for 
this  kind  of  automated  TI  update,  applying  the  control  to  the  contractor's 
product,  but  not  attempting  to  keep  operating  in-house  the  hardware  and  software 
required  to  perform  the  TI  preparation  function.  Other  services  are  not  yet 
benefiting  from  this  lesson;  for  example,  it  looks  as  though  the  Air  Force 
Automated  Technical  Order  System  (ATOS)  is  getting  ready  to  go  through  the 
TRUMP  cycle  again,  ten  years  later. 


Copy  to: 

OPNAV-401E/G.  Cash 
NAVMAT-04342/D.  Weybum 
DMSSO/J.  Richardson 
182/M.  Culpepper 
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CALS  DATA/SOFTWARE  OWNERSHIP  AND  PROPRIETARY  RIGHTS 


1.  The  issue  of  software  rights  is  not  presently  covered  by  the 
FAR.  Presently,  the  void  is  filled  by  each  administrative  agency 
issuing  its  own  clauses  and  regulations.  DoD  has  covered  this  in 
Parts  27  of  the  DoD  FAR  Supplement  and  its  implementing  clause 
52.227-7013  "Rights  in  Technical  Data  and  Computer  Software" 
(formerly  DAR  7-104.9(a)).  These  regulations  set  out  the  rights 
which  the  Government  may  take  in  software  within  these  two 
boundaries : 

a.  As  to  software  required  to  be  originated  or  developed 
under  a  government  contract,  the  Government  takes 
"unlimited  rights." 

b.  As  to  software  developed  with  private  monies  or 
commercial  computer  software,  the  Government  takes 
"restricted  rights"  significantly  restricting  its  use. 

2.  The  DAR/DoD  FAR  Supplement  scheme  intends  to  balance  out 
proprietary  rights  and  the  needs  of  the  Government,  and  has  been 
relatively  successful  in  doing  so.  However,  there  is  a  trend  to 
attempt  to  erode  those  rights  by  current  legislation  and 
pressures  from  Government  procurement  personnel. 

Substantive  issues  include: 

a.  Contractor  Proprietary  Rights  to  Software  Developed 

Under  IRAD  Funds  -  While  the  Government  does  contribute 
to  IRAD,  the  entire  scheme  was  developed  to  encourage 
private  investment  by  permitting  the  Contractor  to 
retain  proprietary  rights  (similar  to  the  patent  rights 
retention  scheme).  However,  the  argument  is  still 
being  faced  by  Contractors  by  those  in  Government 
wanting  to  procure  such  proprietary  items  that  they 
should  take  ownership  to  those  rights.  Some  agencies 
have  proffered  the  argument  that  they  should  take  such 
rights  in  view  of  their  portion  of  overhead  paid  to 
which  development  may  be  charged. 
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Government  Monitoring  of  Rights  -  There  is  some 
question  in  the  minds  of  Contractors  as  to  the  ability 
of  the  Government  to  monitor  and  track  proprietary 
software  in  which  it  has  acquired  some  rights  to  use 
for  limited  purposes.  Additionally,  the  DAR  and  DoD  FAR 
Supplement  encourages  the  Government  to  acquire  only 
those  rights  and  that  software  necessary.  However, 
Contractors  have  recently  been  faced  with  more  requests 
for  acquisition  of  rights  in  software  without  a 
predetermination  having  been  made  by  the  Government 
buyers  as  to  what  is  needed.  This  has  even  occurred  on 
R&D  efforts  in  which  it  is  not  even  known  at  contract 
inception  what  types  of  software  may  be  required. 
Confusion  About  Rights  Acquisition  -  There  has  been 
substantial  confusion  as  to  rights  obtained  in 
software.  While  software  documentation  delivered  under 
a  CDRL  becomes  the  Government's  in  one  sense,  even  if 
the  software  is  provided  with  unlimited  rights,  the 
Contractor  retains  intellectual  property  rights 
therein,  including,  but  not  limited  to,  the  right  to 
license  usage  by  others.  However,  Contractors  are 
finding  themselves  in  disputes  as  to  "ownership" 
granted  by  the  various  levels  of  rights,  and, 
consequently,  wasting  time  and  resources  protecting  the 
residual  rights. 


PROPRIETARY  DATA  RIGHTS  IN  CALS 


In  general,  proprietary  data  does  not  migrate  from  the 
product  data  base  in  CAD/CAM  to  the  logistic  support  files  - 
CALS.  The  prime  contractor  suppliers  do  not  incorporate 
proprietary  data  in  technical  manuals. 

Proprietary  drawings  are  used  to  develop  spare  parts  and  GSE 
provisioning  data;  however,  the  resultant  provisioning  data 
merely  identifies  part  numbers  and  general  descriptions  of  the 
parts  -  not  the  how  to  manufacture  the  part. 

Proprietary  drawings  will  not  reside  in  CALS  -  they  will  be 
in  the  CAD/CAM  file.  The  real  issue  then  becomes  a  data  rights 
issue  of  the  product  definition  in  CAD/CAM. 

Congress  is  attempting  to  legislate  certain  limitations 
including  limits  on  the  time  duration  for  proprietary  rights 
including  third  party  review  of  the  proprietary  of  the  rights. 

The  proprietary  data  rights  issue  should  be  identified  in 
our  CALS  report  but  it  should  be  clearly  stated  that  it  is  not  a 
CALS  issue.  It  is  a  CAD/CAM  issue,  especially  when  we  visualize 
Government  access  to  contractor's  CAD/CAM  file. 

Summary:  It  should  be  recognized  that  these  issues  are  a  brief 

overview  of  a  very  complex  series  of  issues.  CALS  is  merely  an 
additional  set  of  software  to  a  much  larger  software  right  issue. 
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CALS  CONTRACT  METHODOLOGY 


Inherent  to  the  effective  implementation  of  CALS  is  the  clear  underatanding  of  what  is  required  by 


Computer  Aided  Logistics  Support 


transfer  of  large  scale  database  from  contractor  to  user. 


COMPUTER  AIDED  LOGISTICS  SUPPORT  (CALS) 


Contractor  Benefits  -  The  Logistics  Support  Analysis  (LSA)  begins  with  "design  to"  supportability 
requirements  levied  on  the  designer.  This  is  done  through  the  CAD  system  so  the  designer  can  incorporate 
the  required  supportability  features  during  the  design  process  and  establish  supportabillty  data  elements 
in  CALS.  Specific  supportability  design  rules  and  algorithms  must  be  included  in  CAD. 
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INCREASED  LOGISTICS  SUPPORT 


A  computer  network  that  provides  accurate,  near-real-time  information  to  program  managers  is  a  big 
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COMPUTER  AIDED  LOGISTIC  SUPPORT  (CALS) 
"A  PAPERLESS  LOGISTIC  SYSTEM" 


General 

Implementation  of  the  Computer  Aided  Design  and  Computer 
Aided  Manufacturing  (CAD/CAM)  concept  will  result  in  the 
"paperless"  airplane.  This  concept  will  drastically  reduce  the 
nonrecurring  manhours  associated  with  designing  and  developing  a 
new  weapon  system  as  well  as  reducing  the  development  time  from 
go-ahead  to  first  flight.  The  CAD/CAM  data,  electronically 
coupled  to  the  computer-aided  logistic  data  base  in  conjunction 
with  advanced  computer  networks,  presents  opportunities  for  a 
"paperless"  logistic  system.  However,  before  that  can  happen,  a 
definite  change  in  mind  set  and  funding  procedures  will  be 
required.  Logisticians  are  sometimes  referred  to  as  "paper 
pushers"  and  upon  examination  of  the  current  procedures,  this  is 
probably  a  fairly  accurate  assessment.  Computer  Aided  Logistic 
Support,  with  the  vast  amounts  of  data  contained  therein,  will 
inundate  the  logistics  community  with  paper  and  bury  any 
logistics  support  program  unless  steps  are  taken  to  maximize  the 
use  of  this  tool. 


WHAT"S  THE  IMPACT  OF  CALS? 

Logistics  Design 

The  Logistic  Support  Analysis  (LSA)  process  begins  with 
"design  to"  supportabi lity  requirements  levied  on  the  designer. 
This  must  now  be  done  through  the  CAD  system  so  that  the  designer 
can  incorporate  the  required  supportabi lity  features  during  the 
design  process.  CONTRACTOR  IMPACT  -  Specific  supportability 
design  rules  and  algorithms  must  be  included  in  CADD. 

Data  Audit/Approval  Techniques 

As  the  paperless  logistic  system  comes  on-lime,  new  data 
auditing  and  approval  techniques  must  be  developed.  Data 
auditing  in  this  context  refers  to  assuring  integrated  logistics 
support,  i.e.,  all  support  elements  are  in  concert  with  the 
approved  maintenance  plan.  Most  of  this  auditing  can  be  done 
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with  appropriate  edit  and  compare  programs.  Another  form  of 
auditing  is  that  required  to  certify  the  contractor’s  capability 
to  perform  the  LSA  function.  The  approval  techniques  refer  to  the 
requirement  for  up  front  Government  approval  of  the  basic 
maintenance  plan  upon  which  the  support  system  is  built. 
Historically,  this  has  involved  the  delivery  of  multiple  copies  of 
literally  thousands  of  pieces  of  paper  for  manual  review  and 
markup.  CONTRACTOR  IMPACT  -  A  new  technique  utilizing  remote 
access/job  entry  terminals  with  on-line  update  must  be  developed. 
Logistic  Support  Element  Acquisition 


Once  the  maintenance  concept  is  approved  and  the  logistics 
support  resources  are  identified,  how  will  acquisition  be 
accomplished?  Will  each  logistics  support  element  manager  in  the 
Government,  i.e.,  spares,  support  equipment,  technical 
publications,  training  equipment,  etc.,  still  require  their  own 
peculiar  paperwork  for  review  and  approval  prior  to  acquisition? 
If  so,  it  would  certainly  seem  redundant  in  that  the  maintenance 
plan  has  already  been  approved,  and  again,  we  would  not  have  a 
paperless  logistic  system.  LSA  maintenance  plan  has  defined  the 
required  logistic  support  resources,  how  will  they  be  transmitted 
to  the  customer?  We  will  revert  back  to  paper.  GOVERNMENT 
IMPACT  -  In  the  LSA  environment,  the  logistics  support 
requirements  derived  as  a  result  of  a  Government  approved 
maintenance  plan  should  be  transmitted  electronically  to  the 
appropriate  Procurement  agency  and  where  the  capability  exists, 
the  contract  placed  electronically  with  the  true  manufacturer. 
INDUSTRY/CONTRACTOR  IMPACT  -  Government  agencies  must  change 
their  procedures  to  process  logistic  support  requests  and  issue 
purchase  orders  electronically.  This  will  eliminate  the  need  for 
a  large  number  of  government  employees. 


Data  and  File  Transfer  from  Contractor  to  Government  Agenc 


At  some  point  in  time,  the  contractors’  developed  CALS  will 
be  transferred  to  a  Government  agency(s).  Issues  to  be  addressed 
here  are  the  method  of  transferring  (i.e.,  on-line  computer  vs 
mag  tape,  etc.)  and  the  degree  of  software  standardization 


required.  Through  interface  with  the  Air  Force  Requirements  Data 
Bank,  a  Computer  Aided  Logistics  program  could  be  continuously 
updated.  In  the  long  term,  Government  needs  to  define  their 
logistics  data  base  requirements  and  integrate  these  with  their 
systems,  i.e.,  USAF  Requirements  Data  Bank.  In  the  near  term  to 
capitalize  on  emerging  technology,  DoD  should  recognize  that  the 
prime  contractor's  data  base  will  be  transferred  to  the  Logistic 
System  Manager,  i.e.,  SSM  in  USAF  so  that  the  will  NOT  have  to 
recreate  a  weapon  system  file.  The  inventory  managers  (IM's)  can 
operate  on-line  with  the  unique  weapon  system  file.  When  the 
Government  ILS  Data  Bank  was  defined,  each  contractor  will  format 
his  data  for  direct  transfer  to  the  Government  as  the  product 
ends  its  production  cycle.  CONTRACTOR/GOVERNMENT  IMPACT  -  In  the 
near  term  (next  five  years),  the  Government  would  have  to  accept 
selected  prime  contractor  data  bases  using  common  data  access 
terminals.  Government  must  develop  common  logistic  data  base 
elements  so  that  the  near  term  files  could  be  transferred  to  the 
Government  owned  and  operated  data  base.  Provisions  for  updating 
the  file  as  a  result  of  post  production  design  changes 
(Government/contractor  initiated)  must  be  established. 

Utilization  of  CAD/CAM  Data  in  a  "Competitive"  Environment 

In  the  CAD/CAM  environment,  reprocureraent  data  packages  as 
they  are  known  today  will  be  nonexistent.  The  data  will  reside 
in  the  file.  Government  access  will  immediate  to  help  increase 
competition  for  logistic  support  resources.  GOVERNMENT  IMPACT  - 
Eliminate  the  cost  of  acquiring  and  maintaining  reprocureraent 
data  packages.  The  reprocurement  data  in  CAD  will  also  simplify 
Government  transition  from  CFAE  to  GFAE  during  the  production 
cycle  after  system  maturity  and  design  stability  is  attained. 
Summary 

The  impacts  contained  herein  are  just  a  few  of  the  more 
burning  issues  related  to  CALS  and  by  no  means  are  intended  to 
represent  all  of  the  Government/contractor  areas  of  impact. 


He— a 

T7% 


o  -  J 


'-V"* 

vJ 


*  o 


99 
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1.  EXECUTIVE  SUMMARY.  Information  processing  technology  for 
automated  creation  and  delivery  of  product  definition  and  techni¬ 
cal  data  is  being  adopted  throughout  the  defense  industry.  Use 
of  standard  languages  and  data  exchange  formats  is  not  necessary 
for  digital/electronic  transfer  of  graphics  and  text  data.  How¬ 
ever,  such  use  is  essential  to  effectively  capitalize  on  the  cost 
reduction  opportunities  that  computer  technology  offers  for  wea¬ 
pon  system  acquisition.  Industry  recognizes  the  value  of  stan¬ 
dardization,  and  is  contributing  to  the  development  of  a  variety 
of  language  and  data  exchange  standards.  Some  of  these  standards 
can  be  used  to  help  satisfy  DoD  objectives  to  improve  the  effec¬ 
tiveness  and  efficiency  of  weapon  system  acquisition  and  life 
cycle  management.  DoD  should  announce  its  support  for  these 
standards.  Some  of  the  standards  exhibit  deficiencies,  which 
active  DoD  support  and  funding  can  remedy;  others  have  a  plan  for 
evolutionary  development,  which  DoD  support  can  accelerate.  The 
Computer  Aided  Logistics  Support  (CALS)  study  has  already  high¬ 
lighted  DoD's  need  to  interface  these  standards  in  a  wholly 
integrated  logistics  support  structure  linking  weapon  system 
designer  to  weapon  system  manager  and  users.  Principal  stan¬ 
dardization  findings  developed  in  this  paper  are: 

a.  A  few  of  the  various  text  and  graphics  standards  are 
sufficiently  complete  and  widely  enough  accepted  that  a  formal 
DoD  commitment  to  their  use  should  be  made  immediately. 

b.  DoD  should  target  funding  to  development,  validation, 
and  demonstration  of  industry  standards  where  shortcomings  or 
unknowns  preclude  such  a  formal  commitment  at  this  point  in  time, 
but  where  potential  benefits  appear  substantial. 

c.  Standards  integration  requires  more  attention,  more 
emphasis,  and  more  hands-on  application  experience  to  take  full 
advantage  of  standardization  opportunities. 

To  implement  these  findings,  DoD  should  charter  a  lead 
Service  project  office  to  coordinate  the  further  development, 
demonstration,  and  implementation  of  industry  graphics  and  text 
standards.  DoD  should  adopt  the  Standard  Generalized  Markup 
Language  (SGML)  for  text  processing  and  the  Graphics  Kernel 
System  (GKS)  for  two-dimensional  graphics  in  early  1985.  DoD 
should  also  announce  its  intention  to  actively  promote  further 
development  of  the  Initial  Graphics  Exchange  Specification  (IGES) 
for  CAD /CAM  product  definition  transfer,  and  should  adopt  the 
Product  Definition  Exchange  Specification  (IGES*  successor) 
following  its  December  1985  release  by  the  National  Bureau  of 
Standards.  DoD  should  fund  further  IGES  development  and  the 
development  of  standards  interfacing  capability,  as  well  as  a 
series  of  demonstration  projects  applying  these  standards  for 
CAD/CAM  data  delivery  and  automated  authoring  of  technical  docu¬ 
mentation. 

2.  DESCRIPTION  AND  OVERVIEW.  Graphics  and  text  standards  pro- 
vide  a  common  medium  for  either  generation  or  transmission  of 
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graphics  and  text  data.  Common  media  provide  the  data,  program, 
and  programmer  portability  necessary  to  improve  automated  data 
processing  (ADP)  efficiency  and  reduce  the  cost  of  sharing  weapon 
system  acquisition  data  among  prime  contractors,  sub-contractors, 
and  vendors,  as  well  as  between  defense  contractors  and  DoD.  ADP 
systems  in  use  today  still  remain  significantly  hardware  and  soft¬ 
ware  unique;  this  is  especially  true  of  the  Computer  Aided  Design 
and  Computer  Aided  Manufacturing  (CAD/CAM)  systems  and  the  large- 
scale  automated  technical  documentation  authoring  systems  needed 
to  support  weapon  system  acquisition  programs.  Often,  two  sys¬ 
tems  produced  by  the  same  manufacturer  are  so  different  that  they 
cannot  communicate  directly  with  one  another,  let  alone  with 
another  manufacturer's  CAD/CAM  or  authoring  system.  Graphics  and 
text  standards  provide  a  vehicle  for  accomplishing  such  communi¬ 
cation,  or  for  sharing  the  data  produced  by  such  systems.  There 
are  nearly  fifty  national  and  international  organizations,  indus¬ 
try  and  professional  associations,  and  other  groups  involved  in 
the  development  and  review  of  standards  in  these  areas. 

2.1  Types  of  Graphics  and  Text  Standards.  Not  all  standards 
serve  the  same  purpose,  just  as  not  all  accomplish  the  same  range 
of  functions.  This  is  important  not  only  in  understanding  how  a 
standard  should  be  used,  but  also  in  understanding  the  limita¬ 
tions  on  its  use.  One  type  of  standard  specifies  a  language  gram¬ 
mar,  which  allows  program  (and  programmer)  portability  between 
ADP  systems.  Ada,  the  new  programming  language  developed  by  DoD, 
is  such  a  standard.  Program  source  code  written  in  the  American 
National  Standards  Institute  (ANSI)  standard  for  Ada  can  be  run 
on  any  computer  for  which  an  Ada  compiler  has  been  written  and 
validated;  the  compiler  translates  the  standard,  machine-indepen¬ 
dent  Ada  source  code  into  non-standard,  hardware-dependent  object 
code.  Somewhat  like  Ada,  GenCode  is  a  standard  language  grammar 
for  text  markup  and  identification.  Another  type  of  standard 
provides  a  common  file  structure  for  exchanging  data  between 
application  programs  operating  on  different  ADP  systems.  The 
programs  themselves  may  be  in  different  languages,  but  each  uses 
a  system-unique  translator  to  produce  and  read  a  data  file  that 
is  in  a  common  format  which  both  can  understand.  The  Initial 
Graphics  Exchange  Specification  (IGES)  for  CAD/CAM  product  defi¬ 
nition  is  a  standard  of  this  type.  Neither  standard  languages 
nor  standard  exchange  formats  are  necessary  for  transfer  of  gra¬ 
phics  or  text  data,  and  some  degree  of  interchange  capability 
exists  without  such  standards.  But  standardization  is  essential 
to  achieve  real  productivity  benefits;  indeed,  without  the  use  of 
such  standards,  widespread  networking  among  multiple  contractors 
and  DoD  components  would  be  cost  prohibitive. 

For  purposes  of  organization,  this  paper  makes  a  primary 
distinction  between  language  and  file  structure  standards  for 
graphics  and  text.  A  subsequent  distinction  is  also  drawn 
between  CAD/CAM  and  authoring  system  standards.  Other  organiza¬ 
tions  of  this  paper  would  be  possible,  because  many  of  the 
standards  addressed  here  do  not  fit  cleanly  into  a  particular 
category.  For  example,  IGES  is  intended  to  evolve  into  a  "pro- 
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duct  definition"  standard  that  is  much  more  than  simply  a  gra¬ 
phics  file  structure;  VDI  (CGI),  the  Virtual  Device  or  Computer 
Graphics  Interface,  is  a  hardware  interface  standard  for  software 
as  much  as  it  is  a  language  standard;  NAPLPS,  the  North  American 
Presentation  Level  Protocol  Syntax,  which  is  here  classified  as  a 
file  structure  standard,  is  a  data  representation  "product  defini 
tion"  standard  that  is  much  more  than  simply  a  graphics  file 
structure;  VDI  (CGI),  the  Virtual  Device  or  Computer  Graphics 
Interface,  is  a  hardware  interface  standard  for  software  as  much 
as  it  is  a  language  standard;  NAPLPS,  the  North  American  Presen¬ 
tation  Level  Protocol  Syntax,  which  is  here  classified  as  a  file 
structure  standard,  is  a  data  representation  standard  with  some 
language  characteristics  that  depends  on  the  implementing  system 
for  the  exact  format  of  the  file  in  which  the  NAPLPS  data  stream 
is  stored.  While  a  standard  language  (incorporating  a  standard 
file  format)  has  advantages  over  a  standard  data  transmission 
format  alone,  it  is  often  more  difficult  to  obtain  agreement  on, 
particularly  during  a  period  of  technology  emergence.  Both  types 
of  standards  require  hardware-dependent  translators,  even  when 
advertised  as  device  independent,  and  those  for  data  transmission 
can  be  harder  to  develop  and  validate  because  the  range  of  poten¬ 
tial  data  cases  created  by  different  languages  is  much  broader 
than  the  range  of  a  single  language  instruction  set. 

2.2  Graphics  Standards.  Graphics  applications  for  the  compu 
ter  have  evolved  in  part  from  industrial  design  requirements,  and 
in  part  from  consumer  delivery  requirements,  including  publica¬ 
tions,  broadcast  advertising,  and  game/microcomputer  visuals. 
Graphics  standards  are  still  developing.  Except  for  the  North 
American  Presentation  Level  Protocol  Syntax,  or  NAPLPS  (which  has 
some  deficiencies) ,  none  are  complete  or  fully  accepted,  and 
there  are  still  many  hardware/software  unique  graphics  languages 
and  formats  in  use.  Few  DoD  organizations  employ  computer  gra¬ 
phics  software  that  conforms  to  a  proposed  or  de  facto  standard. 
Some  graphics  languages  are  being  pushed  as  de  facto  standards, 
through  free  or  low  cost  licensing  by  the  developer  to  potential 
users,  in  the  hope  that  a  broad  enough  base  of  support  will 
emerge  to  force  official  sanctioning  by  a  standardization  body 
such  as  ANSI.  In  some  cases,  competing  standards  are  being 
developed,  with  survival  expected  to  go  not  necessarily  to  the 
fittest,  but  perhaps  merely  to  the  first  available.  Since  gra¬ 
phics  applications  have  little  value  in  isolation,  graphics 
languages  and  data  transmission  formats  must  include  "hooks,"  or 
bindings,  to  languages/formats  for  alphanumeric  text  and  scienti¬ 
fic  data.  It  is  important  that  these,  too,  be  standardized  to 
facilitate  program  portability. 

2.2.1  Graphics  Language  Standards.  There  is  no  standard 
graphics  language  for  major  industrial  applications  such  as 
CAD/CAM,  because  hardware  investment  costs  are  still  high  enough 
to  discourage  the  equipment  proliferation  which  tends  to  break 
down  barriers  between  proprietary,  competing  software.  There¬ 
fore,  graphics  language  standards  focus  on  lower  cost  micro  and 
minicomputer  applications,  including  automated  authoring  systems. 


simple  word  processing  systems,  and  personal  computers.  Even 
when  mainframe  hardware  is  used,  graphics  requirements  for  these 
applications  also  tend  to  be  much  simpler  than  for  CAD/CAM  sys¬ 
tems,  making  a  standard  graphics  language  easier  to  develop.  The 
leading  contenders  for  graphics  language  standards  are  CORE, 

PMIG,  GKS,  VDI  and  PHIGS. 

2. 2. 1.1  CORE.  CORE  is  a  de  facto  standard  developed  between 
1974  and  1977  by  the  Special  Interest  Group  on  Graphics  of  the 
American  Association  for  Computing  Machinery.  It  supports  three- 
dimensional  graphics,  but  does  not  directly  specify  higher  level 
language  bindings,  thus  hindering  transportability.  Although  no 
longer  universally  viewed  as  "the  emerging  industry  standard," 

CORE  is  still  being  advocated  and  used  in  many  graphics  systems. 
Work  on  development  of  CORE  significantly  declined  with  the 
emergence  of  the  Graphics  Kernel  System  (GKS) . 

2. 2. 1.2  PMIG.  (Programmer's  Minimal  Interface  to  Graphics) 
was  begun  in  1979  as  an  effort  to  make  a  less  sophisticated  ver¬ 
sion  of  CORE  available  to  personal  computer  users  and  BASIC  pro¬ 
grammers.  Some  work  continues  on  PMIG,  although  most  efforts 
ended  when  GKS  was  adopted  as  an  International  Standards  Organiza¬ 
tion  (ISO)  working  item.  PMIG  concepts  have  been  incorporated 
into  GKS. 

2. 2. 1.3  GKS.  (Graphics  Kernel  System)  is  the  current  lead¬ 
ing  contender  for  an  international  industry  graphics  language 
standard.  Initiated  in  Germany  in  the  late  1970's,  it  has  gener¬ 
ally  absorbed  effort  earlier  applied  to  CORE  and  PMIG.  A  complex 
two-dimensional  language  with  standard  bindings  for  intersystem 
transportability,  it  handles  both  vector  and  raster  graphics,  and 
has  the  capability  to  zoom  in  and  pan  across  large,  sophisticated 
graphics  such  as  might  be  developed  for  technical  publications. 

2. 2. 1.4  VDI .  (Virtual  Device  Interface,  recently  renamed 
the  Computer  Graphics  Interface,  or  CGI)  is  a  different  kind  of 
graphics  language  standard.  Whereas  CORE  and  GKS  provide  appli¬ 
cation  program  interfacing  but  require  complex  machine-unique 
device  driver/translators,  VDI  is  being  developed  specifically  to 
address  the  device  interface  problem.  VDI  will  utilize  much 
simpler  machine-unique  device  drivers  which  may  eventually  be 
provided  through  a  standard  hardware  connector.  Still  under 
development,  VDI  is  expected  to  be  less  complex,  and  hence 
faster,  than  GKS.  Most  programmers  will  employ  sophisticated 
graphics  languages  such  as  CORE,  GKS,  and  PHIGS  that  use  VDI 
device  drivers;  few  will  use  VDI  directly. 

2. 2. 1.5  PHIGS .  (Programmer's  Hierarchical  Interactive  Gra¬ 
phics  Standard)  is  a  "standard  of  the  future,"  the  first  planned 
graphics  language  standard  which  may  be  usable  for  CAD/CAM  appli¬ 
cations.  Presently  an  ANSI  and  ISO  working  item  offering  draft 
approaches  to  resolution  of  CORE  and  GKS  deficiencies,  PHIGS  is 
planned  to  be  a  partially  compatible  extension  of  GKS  with  addi- 
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tional  levels  (hierarchies)  of  building  blocks,  three-dimension¬ 
ality,  faster  response  time,  and  lower  overhead  requirements. 

2.2.2  Graphics  File  Structure  Standards.  In  the  absence  of 
a  hardware  independent  standard  graphics  language,  a  standard 
data  exchange  format  provides  the  best  common  medium  for  multi¬ 
user  sharing  of  graphics  data,  such  as  commonly  occurs  among 
prime  and  subcontractors  involved  in  CAD/CAM  for  a  major  weapon 
system.  Of  course,  nonstandard  direct  translators  between 
graphics  systems  can  be  used  for  data  exchange.  However,  the 
development  cost  for  such  translators  becomes  prohibitive  as  the 
number  of  unique  graphics  systems  proliferates.  Standard  data 
file  structures  also  require  translator  development,  but  only 
need  translators  between  the  unique  graphics  system  and  the  stan¬ 
dard  format,  not  between  the  unique  graphics  system  and  every 
other  unique  graphics  system.  On  the  other  hand,  translator 
development  cost  (and  time)  savings  can  be  offset  by  complexity 
problems  requiring  extraordinary  attention  to  translator  valida¬ 
tion.  The  standard  data  file  structure  must  be  as  rich  -  meaning 
as  sophisticated,  even  if  not  as  complex  -  as  the  most  sophisti¬ 
cated  system  with  which  it  interfaces,  or  it  may  not  be  able  to 
adequately  represent  the  full  range  of  graphics  data  passed  to 
it,  nor  accurately  communicate  that  data  through  another  trans¬ 
lator  (usually  written  by  an  entirely  different  team  of  pro¬ 
grammers)  to  another  graphics  system.  Hence,  standard  file 
structures  for  graphics  data  are  easier  to  develop  for  simple 
graphics  languages;  a  data  exchange  standard  for  CAD/CAM  systems 
exists,  but  is  still  incomplete  and  imperfectly  implemented.  The 
three  principal  candidates  for  file  structure  standards  are 
NAPLPS,  VDM,  and  IGES,  each  of  which  has  a  different  community  of 
interest. 

2. 2. 2.1  NAPLPS.  (North  American  Presentation  Level  Protocol 
Syntax)  was  developed  for  the  videotex  market  during  1981-82, 
based  on  a  series  of  European  and  Canadian  efforts  dating  back  to 
the  mid-1970's.  It  primarily  provides  two-dimensional  text  and 
graphics  transfer  through  the  use  of  redefinable  control  and 
graphics  character  sets.  Its  wide  versatility  makes  it  popular 
for  a  variety  of  graphics  communication  and  broadcast  applica¬ 
tions.  It  is  a  data  representation  standard  with  some  language 
characteristics,  rather  than  a  file  structure  standard. 

2. 2. 2. 2  VDM.  (Virtual  Device  Metafile,  recently  renamed  the 
Computer  Graphics  Metafile,  or  CGM)  is  a  storage/communications 
medium  specifically  oriented  to  graphics,  developed  since  1980  as 
a  complement  to  GKS  and  VDI.  It  is  still  in  the  draft  stage,  and 
just  as  existing  hardware-unique  data  transfer  formats  have  many 
VDM- like  features,  so  does  NAPLPS,  which  is  more  popular  than  VDM 
in  the  graphics  community.  What  VDM  offers  that  NAPLPS  lacks  is 
a  standard  storage  format.  Like  VDI,  VDM  development  is  not 
directly  linked  to  development  of  GKS.  However,  because  it  has 
been  designed  to  interface  with  GKS  and  VDI,  VDM  may  achieve  the 
support  GKS  now  has,  although  it  has  not  done  so  as  yet. 
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2. 2. 2. 3  IGES .  (Initial  Graphics  Exchange  Specification)  is 
a  neutral  data  format  for  product  definition  data  (including  both 
geometry  and  technical  information)  generated  in  the  CAD/CAM 
world,  as  opposed  to  simpler  NAPLPS  and  VDM  "picture  transfer." 
Development  began  in  1979,  with  several  versions  already 
released,  but  remains  incomplete  and  principally  oriented  toward 
mechanical  applications.  IGES  deserves  the  significant  attention 
it  is  receiving  because  it  is  the  only  meaningful  American  stan¬ 
dardization  effort  underway  in  the  CAD/CAM  world.  However,  the 
complexity  of  CAD/ CAM  graphics  makes  development  of  accurate, 
verifiable  translators  to  and  from  the  neutral  IGES  format  a 
major  problem  to  be  overcome,  to  which  the  IGES  development  com¬ 
mittee,  vendors,  and  users  have  not  yet  applied  adequate  atten¬ 
tion.  Another  problem  only  beginning  to  be  seriously  tackled  is 
the  development  of  interface  translators  between  IGES-formatted 
CAD/CAM  graphics  and  the  graphics  standards  for  delivery/presen¬ 
tation  systems  (eg,  GKS  language  or  VDM  file  format  standards) 
which  would  be  used  for  illustration  of  technical  manuals. 

2.3  Text  Standards .  Efforts  to  develop  text  standards  for 
the  publishing  and  typesetting  industries  have  a  long  history, 
but  standardization  of  languages  and  formats  for  automated  author¬ 
ing  systems  is  of  much  more  recent  advent.  The  "simplicity"  of 
text  and  the  availability  of  ASCII  (American  Standard  Code  for 
Information  Interchange)  coding  used  in  teletype  communications 
and  a  wide  variety  of  computer  applications  slowed  standardiza¬ 
tion  of  authoring  system  software.  This  allowed  time  for  wide¬ 
spread  proliferation  of  vendor-unique  text  processing  systems, 
many  of  which  employ  elaborate  control  code  schemes  to  satisfy 
demands  for  user  friendliness  and  special  output  formatting.  The 
difficulty  of  exchanging  these  non-standardized  control  code 
structures  among  dissimilar  text  processing  systems  provided  the 
pressure  necessary  for  development  of  text  standards,  although 
the  significant  user  investment  in  text  processing  hardware  has 
encouraged  manufacturers  to  continue  attempting  to  establish 
their  own  unique  systems  (such  as  IBM's  Document  Content  Architec¬ 
ture  or  XEROX'S  Interscript)  as  de  facto  standards.  ISO's  Office 
Document  Architecture  standard  may  eventually  emerge  as  the  prin¬ 
cipal  contender  among  a  variety  of  standardization  efforts  in  the 
text  processing  arena.  However,  for  the  near  term,  there  are 
essentially  only  two  community-wide  text  standards  exist  in 
nearly  completed  form  that  DoD  should  consider;  these  are  SGML, 
together  with  its  precursor  GenCode,  and  DIF. 

2.3.1  SGML.  (Standard  Generalized  Markup  Language)  is  a 
method  for  coding  text  files  which  separates  document  content 
from  the  processing  instructions  that  define  the  output  form  and 
format  of  the  document.  The  concept  of  a  markup  standard  is  over 
fifteen  years  old,  but  SGML  itself  is  fairly  recent,  and  is  still 
awaiting  final  adoption.  It  is  a  text  processing  language  large¬ 
ly  based  on  GenCode,  a  trademarked  generic  coding  structure 
developed  by  the  Graphic  Communications  Association,  which  is  in 
widespread  use.  SGML/GenCode  by  itself  describes  the  coding  of 
the  document  structure,  but  not  the  processing  or  appearance  of 
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the  marked  up  document.  Nor  is  it  a  complete  office  document 
architecture  because  an  SGML  implementation  includes  a  language, 
not  merely  a  coding  structure,  it  can  be  easily  linked  to  other 
languages,  such  as  GKS,  for  which  specific  binding  provisions  are 
being  incorporated  in  the  SGML  standard.  However,  SGML  does  not 
provide  a  mark-up  capability  for  these  incorporated  graphics. 

SGML  provides  a  device-independent  syntax  for  using  text  coding 
identifiers  defined  by  the  user,  which  are  then  interpreted  by  a 
device-dependent  preprocessor. 

2.3.2  DIF.  (Document  Interchange  Format)  is  a  less  sophis¬ 
ticated  neutral  data  exchange  format  for  text.  DIF  utilizes 
translators  to  convert  system-unique  text  processor  control 
coding  to  and  from  the  DIF  representation,  similar  to  the  way 
IGES  acts  as  a  data  exchange  format  for  CAD/CAM  systems.  DIF  is 
attractive  to  those  who  have  large  investments  in  existing  pro¬ 
prietary  text  processing  systems  which  must  communicate  with 
other  proprietary  systems.  Unlike  IGES,  however,  DIF  can  be  seen 
as  a  short  term  standard,  since  the  growing  acceptance  of  SGML/ 
GenCode  for  new  text  processing  systems  may  be  expected  to  gra¬ 
dually  displace  the  DIF  market. 

2.4  Merging  Text  and  Graphics  Standards.  In  today's  auto¬ 
mated  world,  neither  graphics  nor  text  is  used  in  isolation, 
except  on  the  simplest  word  processing  systems.  Eventually,  a 
joint  graphics  and  text  standard  such  as  ISO's  Office  Document 
Architecture  may  emerge,  although  that  day  is  a  long  time  in  the 
future.  Graphics  standards  which  provide  for  encoded  text  attri¬ 
butes  such  as  IGES,  text  standards  which  allow  block  insertion  of 
graphics  such  as  SGML,  and  dual-form  transmission  formats  such  as 
NAPLPS,  are  the  nearest  current  approach  to  a  joint  standard. 
Hence,  if  the  objective  is  to  integrate  both  text  and  graphics 
for  CAD/CAM  and  automated  authoring,  a  combination  of  standards 
will  have  to  be  considered.  Translators  or  internal  bindings 
will  be  needed  to  link  text/graphics  data  or  application  programs 
This  is  true  whether  graphics  and  text  data  is  stored  in  a 
single,  integrated  data  base,  or  in  separate  data  bases  linked 
through  data  base  management  system  pointers.  To  the  extent 
translators  and  bindings  must  be  developed,  test  and  validation 
will  become  an  important  and  costly  issue. 

3 .  POD  OBJECTIVES.  The  Joint  Indus try/DoD  Task  Force  on  Com¬ 
puter  Aided  Logistics  Support  is  defining  a  set  of  DoD  objectives 
which  focus  on  the  use  of  existing  and  emerging  computer  techno¬ 
logy  to  enhance  the  current  process  for  designing  more  support¬ 
able  weapon  systems,  planning  better  support  for  those  weapon 
systems,  improving  the  timeliness  and  quality  of  logistics 
support  throughout  the  system  life  cycle,  and  reducing  the  cost 
of  weapon  system  acquisition  and  support.  These  objectives  have 
to  be  achieved  within  the  framework  of  a  network  of  prime  contrac 
tors,  subcontractors,  vendors,  and  government  activities  who  must 
exchange  a  broad  spectrum  of  technical  data  about  each  weapon 
system.  This  includes  product  definition,  manufacturing  process, 
configuration  management,  training  and  maintenance,  and  other 
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logistics  support  data.  Graphics  and  text  standards  provide  a 
vehicle  to  support  and  facilitate  actions  undertaken  to  achieve 
these  objectives.  Proliferation  of  non-standard  or  proprietary 
data  exchange  techniques  can  seriously  impede  accomplishing  these 
objectives.  Because  the  United  States  is  several  years  ahead  of 
other  nations  in  implementing  computer  technology  in  these  areas, 
it  is  imperative  that  DoD  vigorously  support  the  appropriate  stan 
dardization  initiatives. 

3.1  Principal  Goal.  The  principal  goal  of  the  Department  of 
Defense  that  is  relevant  to  the  issue  of  graphics  and  text  stan¬ 
dards  should  be  to  improve  the  capability  of  defense  contractors 
and  the  Military  Departments  to  exchange  digital  data  among  dif¬ 
ferent  CAD/CAM,  automated  authoring,  drawing  repository,  and 
configuration  management  systems.  Neutral  data  transmission  for¬ 
mats  supported  by  validated  translators  represent  a  minimum 
requirement  for  meeting  this  goal,  since  long-term  proliferation 
of  direct  system- to- system  translators  is  both  impractical  and 
cost  prohibitive.  Common  languages  (incorporating  or  supported 
by  neutral  data  exchange  and  storage  formats)  represent  a 
preferred  alternative,  since  these  improve  program  portability 
and  programmer  productivity.  Data  base  management  standards  and 
common  communication  protocols,  or  protocol  bridges,  at  the  lower 
levels  of  the  International  Standards  Organization  (ISO)  Open 
Systems  Interconnection  model,  will  also  be  needed,  but  are  not 
addressed  by  this  paper. 

3.2  Specific  Objectives.  This  DoD  goal  translates  into  more 
specific  objectives,  as  follows: 

a.  Improve  the  ability  of  defense  subcontractors  and 
prime  contractors  to  share/exchange  CAD/CAM  data,  to  provide 
product  definition  data  in  a  common  format  to  the  Military  Depart 
ments,  and  to  archive  CAD/CAM  and  product  definition  data  in  a 
neutral,  hardware  transparent  format  that  is  retrievable  and 
usable  on  later  generations  of  computer  equipment. 

b.  Encourage  use  throughout  the  defense  industry  of 
automated  authoring  capabilities,  such  as  those  widely  used  in 
the  publishing  community,  for  preparation,  update,  and  delivery 
of  technical  documentation  throughout  the  weapon  system  life 
cycle . 

c.  Ensure  the  capability  to  implement  a  CALS  system 
architecture  which  maximizes  the  concept  of  "single-point  entry" 
of  graphics  and  text  data  into  an  automated  delivery/retrieval 
system.  Satisfying  this  objective  would  involve  the  ability  to 
communicate  product  definition  and  graphics  data  in  digital  form 
from  CAD  to  CAM  systems,  and  from  these  systems  to  engineering 
drawing  repositories/archives,  configuration  managers,  engineer¬ 
ing  support  activities,  and  authoring  systems  for  technical 
manuals,  training  publications,  and  maintenance/operator  aids. 
Similarly,  textual  data  would  be  passed  from  design/manufacturing 
to  logistics  support  analysis,  and  to  publication  authoring.  At 


each  point  the  content  of  the  data  might  be  expanded,  changed,  or 
compressed,  and  the  form  might  be  revised,  but  the  requirement 
for  re-input  of  data  previously  created  would  be  eliminated. 

d.  Provide  for  electronic  delivery  of  weapon  support 
data  to  all  users  in  a  secure  environment,  to  improve  data 
quality  and  timeliness,  and  to  more  efficiently  manage  the  large 
volumes  of  data  involved. 

3.3  Policy  Issues.  Among  the  key  policy  issues  related  to 
graphics  and  text  standardization  which  are  emerging  from  the 
CALS  study  are  the  following: 

a.  Existing  policies  do  not  support  a  minimum  set  of 
standards  for  digital  acquisition  and  transfer  of  technical  data 
for  weapon  system  logistics  support  to  (and  among)  government 
users . 

b.  Near  term  and  long  range  plans  to  achieve  interoper¬ 
ability  and  interchangeability  of  digital  weapon  support  techni¬ 
cal  data  do  not  exist. 

c.  A  standardized  set  of  data  elements  for  maintaining 
technical  information  electronically  during  the  weapon  system 
acquisition  process  does  not  exist. 

d.  Existing  DoD  plans  for  providing  long-haul  and  area 
data  communications  services  (the  Defense  Data  Network)  may  not 
support  the  volume  of  CALS  data  envisioned. 

4.  EVALUATION  AND  CURRENT  STATUS.  The  scope  of  graphics  and 
text  standardization  efforts  was  briefly  surveyed  in  Section  2. 
This  section  describes  the  evolution  of  those  standards,  and 
identifies  for  further  discussion  those  which  appear  to  have  the 
greatest  potential  for  satisfying  the  DoD  objectives  listed  in 
Section  3.  These  are  placed  within  the  context  of  current  usage 
within  government  and  industry,  as  well  as  current  expectations 
as  to  their  future  utility. 

4.1  Development  and  Status .  Graphics  and  text  standardiza¬ 
tion  has  lagged  the  computer  technology  developed  to  utilize 
those  capabilities.  In  an  era  of  explosive  technology  growth  in 
these  areas,  a  lag  of  even  two  or  three  years  means  that  a  stan¬ 
dard  can  become  out  of  date  before  it  can  be  applied.  This  point 
is  critical  because  few  of  the  existing  or  proposed  standards  are 
entirely  adequate  to  the  task  they  are  designed  to  address. 

IGES,  for  example,  is  widely  touted  as  the  only  practical 
approach  to  exchanging  CAD/CAM  data  and  is  widely  used  for  that 
purpose.  Yet  IGES  is  just  as  widely  criticized  for  being  incom¬ 
plete,  difficult  and  costly  to  use,  and  sometimes  untrustworthy 
even  for  the  transmission  of  those  parts  of  CAD/CAM  data  which  it 
does  address.  For  more  sophisticated  applications  of  graphics 
and  text  (such  as  CAD/CAM),  only  a  proprietary  system  interfaced 
with  the  same  proprietary  system  implemented  on  virtually  the 


111 


same  hardware  configuration  offers  reasonable  assurance  of  com¬ 
pletely  accurate  data  exchange.  Yet  it  is  in  CAD/CAM  applica¬ 
tions  that  a  proprietary  system  is  least  likely  to  be  adopted  as 
a  de  facto  standard  by  a  large  number  of  users,  as  has  occurred 
(for  example)  with  CORE.  Although  this  suggests  a  nearly  insolu¬ 
ble  problem,  in  fact,  DoD  can  make  a  significant  contribution  to 
the  development,  validation,  and  application  of  these  standards. 
This  paper  proposes  a  course  of  action  through  which  DoD  can 
judiciously  apply  its  resources  to  reduce  the  standardization  lag 
time  and  facilitate  the  implementation  of  those  standards  that 
best  meet  DoD's  needs. 

4.1.1  CAD/CAM  Standards .  As  noted,  IGES  is  the  only 
presently  available  CAD/CAM  standard,  albeit  an  incomplete 
and  controversial  one.  PHIGS,  which  is  in  essence  an  evolu¬ 
tionary  development  of  graphics  standards  for  delivery/presen¬ 
tation  systems,  has  some  potential  for  becoming  a  "first  cut" 
CAD/CAM  graphics  language  standard  but  is  still  too  far  from 
completion  to  evaluate.  Even  when  complete,  PHIGS  will  be 
only  a  graphics  standard,  and  still  will  not  address  full 
product  definition,  which  is  the  key  to  establishing  the  CAD/ 

CAM  interface  within  a  Computer  Integrated  Manufacturing 
(CIM)  environment.  Meanwhile,  the  major  CAD/CAM  vendors 
would  each  be  happy  to  see  their  system  emerge  as  a  de  facto 
standard.  This  is  unlikely  to  occur,  although  ongoing  propri¬ 
etary  and  non-proprietary  work  in  electronics  and  electrical 
applications  may  provide  the  foundations  for  future  Versions 
of  IGES,  just  as  Boeing's  CAD/CAM  Integrated  Information 
Network  (CIIN)  provided  major  input  to  IGES  Version  1.0. 

4. 1.1.1  IGES.  IGES  originated  in  the  Air  Force's  Inte¬ 
grated  Computer  Aided  Manufacturing  (ICAM)  program.  Using 
development  funding  provided  by  the  Military  Services  and 
NASA,  the  National  Bureau  of  Standards  (NBS)  and  several 
industry  representatives  developed  the  initial  version  of  the 
standard  during  the  fall  of  1979.  This  initial  version  was 
based  in  large  part  of  Boeing's  CIIN  format,  with  enhance¬ 
ments  from  General  Electric's  Neutral  Data  Base  work  and 
others,  and  was  specifically  oriented  toward  mechanical  appli¬ 
cations  that  dominated  existing  CAD  implementations  within 
the  aerospace  industry;  it  was  published  as  IGES  Version  1.0 
in  January  1980.  In  May  1980,  ANSI  began  incorporating  IGES 
into  a  draft  standard  on  Digital  Representation  for  Communica¬ 
tion  of  Product  Definition  Data  Y14.26M).  Even  before  the 
draft  was  released  for  public  comment  in  October  1980,  three 
of  the  major  CAD/CAM  vendors  announced  initial  IGES  transla¬ 
tors.  However,  limited  intersystem  transfer  of  IGES  data  was 
not  publicly  demonstrated  until  December  1981.  By  then,  the 
ANSI  standard  containing  IGES  Version  1.3  had  been  published 
(September  1981),  and  shortly  afterward  DoD  published  an 
Acceptance  Notice  for  IGES  (January  1982).  Version  2.0  of 
IGES  was  released  by  the  IGES  committee  in  July  1982,  and 
subsequently  proposed  for  incorporation  into  the  Y14.26M  ANSI 
standard,  although  this  work  was  never  completed.  Version 


2.0  and  Version  3.0  (formerly  called  Version  2.1,  scheduled 
for  release  in  December  1984  or  early  1985)  contain  a  number 
of  technical  enhancements  which  are  mostly  upward  compatible 
from  earlier  versions,  as  well  as  extensions  into  finite  ele¬ 
ment  modeling  and  printed  wiring  board  data.  While 
development  of  Version  2.1  continues,  efforts  to  produce  the 
next  version  of  IGES  (originally  labeled  as  Version  3.0)  with 
extensions  into  solid  geometry  and  actual  product  definition 
are  also  underway.  This  "next  generation"  IGES  will  be  a 
key  step  in  linking  CAD  and  CAM  into  a  true  CIM  environment, 
based  on  exchange  of  product  definition  data.  When  "Version 
3.0"  (retitled  as  the  "Product  Definition  Exchange  Standard") 
is  available  in  late  1985  or  early  1986,  it  will  also 
incorporate  some  of  the  features  of  IGES's  principal  European 
competitors,  and  (hopefully)  provide  a  basis  for  ISO 
acceptance  of  IGES.  For  example,  the  French  SET  exchange 
standard  provides  a  more  efficient  file  structure  than  IGES, 
an  important  factor  for  high  volume  electronic  transmission 
of  product  definition  or  drawing  data.  This  is  one  of  the 
major  areas  being  addressed  by  the  Product  Definition  Data 
Interface  project  discussed  in  Sections  5.1.2.  and  5.1.3.  A 
number  of  companies  and  committees  are  working  on  other  IGES 
enhancements.  These  include  not  only  finite  element  modeling 
within  mechanical  applications,  but  also  electrical, 
electronic,  hydraulic,  architectural,  and  other  extensions. 

Over  a  dozen  CAD/CAM  vendors  have  demonstrated  IGES 
translators,  or  provided  test  data,  and  a  score  of  others  are 
publicly  committed  to  development  of  translators.  Hence, 

American  CAD/CAM  manufacturers  and  users  have  largely 
accepted  IGES  data  standardization.  However,  a  recent  Air 
Force  ICAM  study  confirmed  earlier  findings  that  existing 
IGES  translators  exhibit  inadequacies  which  still  restrict 
such  use. 

4. 1.1. 2  PHIGS .  One  reason  why  CORE  was  not  immediately 
accepted  by  ANSI  in  1977  was  the  desire  to  create  a  "Super  CORE" 
standard.  Once  GKS  had  been  accepted  as  a  graphics  standardiza¬ 
tion  working  item  by  the  International  Standards  Organization, 
ANSI's  hoped-for  Super  CORE  won  redefinition  as  the  proposed 
"next  step  up"  in  graphics  standards.  The  result  will  be  PHIGS, 
which  is  presently  a  set  of  objectives,  issues,  and  proposed 
approaches  incorporated  in  a  draft  standard  that  will  be  avail¬ 
able  for  public  review  in  mid  1985.  Then  potential  users  will  be 
able  to  determine  if  PHIGS  will  provide  even  a  preliminary  CAD/ 
CAM  graphics  language  standard.  PHIGS  is  presently  intended  to 
be  a  major  upgrade  of  GKS  offering  three-dimensional  (vice  GKS's 
two-dimensional)  displays  and  rotation  capability,  additional 
levels  of  hierarchical  segmentation  (called  structures),  and  the 
faster  response  time  needed  by  dynamic  CAD/CAM  systems,  all 
within  reduced  program  overhead.  PHIGS  is  being  specifically 
designed  for  highly  interactive  display  and  manipulation  of  large 
graphic  data  bases  stored  both  on-line  (i.e.,  RAM  disks)  and 
off-line.  Hence,  while  GKS  is  a  stepping-off  point  for  PHIGS, 
PHIGS  is  deliberately  not  "GKS  plus".  Some  GKS  features  were 
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excluded  because  it  was  perceived  that  they  would  compromise  the 
efficiency  of  PHIGS.  Other  features  are  necessarily  different 
because  PHIGS  is  attempting  to  accomplish  more  than  GKS.  But 
PHIGS  maintains  many  basic  GKS  concepts,  and  it  is  expected  that 
a  GKS  shell  can  be  written  around  a  PHIGS  kernel  for  GKS  users. 
Of  course,  the  only  present  implementations  of  PHIGS  are  experi¬ 
mental,  such  as  that  underway  at  Rensselaer  Polytechnic  Insti¬ 
tute  . 


4.1.2.  Delivery/Presentation  (Authoring  System)  Standards. 
Automated  authoring  systems  represent  only  one  variety  of  deli¬ 
very  and  presentation  system.  Others  include  graphic  arts  for 
television  or  advertising,  mapping  and  chartmaking,  photographic 
conversion/display,  etc.  These  all  have  defense  applications  of 
greater  or  lesser  significance,  and  they  all  share  a  common 
interest  in  text  and  graphics  standardization.  Even  though  the 
emphasis  changes  from  application  to  application,  there  is  no 
form  of  delivery  or  presentation  system  which  is  totally  disin¬ 
terested  in  one  particular  type  of  standard.  Hence,  the  stan¬ 


dards  addressed  here  as  "authoring  system  standards”  have  usually 
been  developed  to  support  a  wider  audience,  and  frequently  have 
more  extensive  capability  than  an  authoring  system  per  se 
requires.  For  example,  only  time  will  tell  whether  PHIGS  will 
emerge  as  a  high-level  standard  for  authoring  systems,  or  a  low- 
level  standard  for  CAD/CAM  systems.  Similarly,  GenCode  presently 
provides  more  extensive  capability  for  text  markup  than  is  gener¬ 
ally  required  for  military  technical  publications,  yet  it  is  the 
obvious  preferred  standard  for  that  application  at  this  point  in 
time.  Developments  such  as  ISO's  Office  Document  Architecture 
are  not  yet  ready  for  use. 


4. 1.2.1  Authoring  System  Text  Standards.  GenCode  and  SGML 
are  gaining  widespread  acceptance,  both  in  the  United  States  and 
in  Europe.  But  -  especially  at  the  low  cost,  word  processor  end 
of  the  scale  of  automated  authoring  systems  -  GenCode  and  SGML 
still  face  stiff  competition  from  proprietary  text  processing 
systems  whose  manufacturers  and  owner/users  have  a  vested  inter¬ 
est  in  not  adopting  any  standard  text  language.  DIF  responds  to 
this  problem  by  providing  a  common  interchange  format  for  text 
and  for  a  common  subset  of  text  processor  control  codes.  How¬ 
ever,  DIF  can  be  perceived  as  a  temporary  solution,  the  require¬ 
ment  for  which  can  be  largely  bounded  by  the  life  of  existing 
equipment  investments. 

4. 1.2. 1.1  SGML.  Discussion  of  standardized  generic  text 
markup  for  typesetting  and  composition  dates  from  the  late  1960's 
and  early  1970's,  with  active  support  from  the  Association  of 
American  Publishers,  the  Graphic  Communications  Association 
(GCA),  some  federal  agencies  such  as  the  Internal  Revenue  Ser¬ 
vice,  and  various  contractors.  Generic  text  markup  can  be  done 
in  a  variety  of  ways,  and  the  SGML/GenCode  standard  is  only  one 
of  them.  The  Association  of  American  Publishers  has  a  generic 
text  markup  system  developed  as  part  of  its  Electronic  Manuscript 
Project;  proprietary  systems  such  as  IBM's  GenCode-like  GML  are 
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in  use;  ISO,  ANSI,  and  industry  associations  have  seen  a  variety 
of  generic  tagging  approaches  put  into  experimental  or  opera¬ 
tional  use.  During  the  1970’s,  GCA  proceeded  with  development  of 
GenCode,  which  forms  the  core  of  the  SGML  standard  drafted  by 
ANSI  and  ISO  during  the  1980' s.  The  standard  adds  to  this 
GenCode  core  a  proposed  text  programming  language  through  which 
the  independent  SGML/GenCode  document  markup  language  could  be 
implemented,  along  with  entry/edit  and  format  composition  applica 
tions,  and  GKS  binding.  Translator  development  for  specific  hard 
ware  applications  is  not  addressed  because  it  is  not  considered 
to  be  a  major  implementation  problem.  The  SGML  draft  was  publish 
ed  by  ISO  in  June  1983,  and  at  the  same  time  GCA  published  Gen¬ 
Code  as  a  stand-alone,  "trial  use"  standard.  The  GenCode  portion 
of  SGML  was  accepted  by  DoD  in  August  1983,  and  is  presently  in 
use  not  only  within  DoD,  but  other  federal  agencies  as  well. 
GenCode 's  increasing  acceptance  and  use  in  industry,  especially 
the  mass  market  publishing  community,  makes  it  and  SGML  the  "no 
contest"  standards  of  choice  for  text  processing.  The  complete 
SGML  will  be  adopted  as  a  formal  standard  within  the  next  several 
months.  Meanwhile,  GenCode  Change  1  is  being  processed  for  DoD 
acceptance.  The  defense  industry  lags  in  implementation  of 
GenCode,  but  only  because  of  fewer  direct  ties  to  the  "publishing 
industry,"  in  which  the  document  itself  is  an  end  product.  There 
is  no  significant  opposition  to  GenCode,  although  the  effort  by 
some  equipment  manufacturers  to  gain  market  share  for  their  own 
proprietary  text  processing  systems  continues.  Eventually,  SGML 
may  be  subsumed  by  ISO's  Office  Document  Architecture,  but  that 
lies  several  years  in  the  future. 

4. 1.2. 1.2  DIF.  DIF  provides  a  vehicle  whereby  those  propri¬ 
etary  text  processing  systems  can  satisfy  the  requirement  to 
exchange  data,  without  themselves  employing  a  standard  language. 
DIF  was  developed  by  the  National  Bureau  of  Standards  at  the 
request  of  the  Navy,  and  published  by  them  in  early  1984.  It  is 
presently  considered  to  be  an  "interim"  Navy  standard  pending 
completion  of  staff  coordination.  DIF  has  broader  applications 
as  well;  for  example,  non-text  processing  applications  accessible 
through  a  proprietary  word  processing  system  can  generate  DIF- 
formatted  output  files,  which  can  then  be  input  to  other  DIF-com¬ 
patible  text  processing  systems  for  composition.  Eventually, 

SGML  will  also  provide  this  same  capability,  as  it  already  plans 
to  do  with  GKS  graphics,  as  well  as  with  DIF-formatted  text  files 
Once  this  flexibility  is  fully  incorporated  into  SGML,  DIF's 
lifespan  will  be  largely  measurable  by  that  of  the  proprietary 
systems  then  in  use. 

4. 1.2. 2  Authoring  System  Graphics  Standards.  There  is  no 
"authoring  system  graphics  standard;"  there  are  several  delivery/ 
presentation  graphics  standards  that  can  be  used  for  illustration 
of  technical  documentation,  plus  the  usual  host  of  proprietary 
systems.  There  is  serious  controversy  among  advocates  of  the 
various  approaches.  Among  the  five  contenders  for  "the"  graphics 
language  standard  (CORE,  PMIG,  GKS,  VDI,  and  PHIGS) ,  two  may  be 
set  aside.  PMIG,  as  noted  in  Section  2. 2. 1.2,  is  a  side  channel 


from  the  mainstream,  not  really  applicable  to  current  and  future 
automated  authoring.  PHIGS  is  a  standard  yet  to  be  developed  and 
applied;  pragmatically,  whatever  attention  or  support  it  receives 
should  come  from  its  potential  application  to  CAD/CAM/CAE,  at 
least  until  the  lingering  debate  over  CORE  and  GKS  is  settled. 
(While  VDI  can  be  used  independently  for  graphics  programming,  it 
very  rarely  will  be.  Graphics  programming  will  be  done  using 
CORE  or  GKS  (or  PHIGS),  which  will  then  access  VDI  device  drivers 
for  maximum  hardware  independence.)  Thus,  the  three  principal 
graphics  language  standards  of  interest  are  CORE,  GKS,  and  VDI. 
And,  of  course,  there  are  also  the  two  contenders  for  data  stor¬ 
age  and  transfer  -  VDM  and  NAPLPS. 

4. 1.2. 2.1  CORE.  In  part,  the  graphics  standards  controversy 
is  a  function  of  advocacy  politics,  sunk  cost  investments,  and 
even  nationalism.  But  there  are  technical  advantages  and  disad¬ 
vantages  as  well.  CORE,  the  oldest  of  the  proposed  graphics 
language  standards,  is  well  structured  and  conceptually  simpler 
than  GKS.  It  also  supports  a  three-dimensional  capability,  which 
GKS  lacks.  Hence,  it  offers  the  delivery/presentation  community 
some  significant  advantages,  especially  for  annimated  real  time 
or  interactive  visual  arts.  CORE  was  developed  between  1976  and 
1979  by  a  subgroup  of  the  American  Association  for  Computing 
Machinery,  after  a  five-year  period  during  which  there  had  been 
much  discussion  of,  but  only  limited  progress  toward  development 
of  a  graphics  language  standard.  Because  it  was  the  first  real 
graphics  standard,  and  because  it  was  both  comprehensive  and 
simple  to  use,  it  quickly  gained  wide  user  support.  Automated 
authoring  system  users  may  be  attracted  by  its  simplicity,  and 
its  three-dimensional  capability  offers  potential  advantages  in 
some  areas,  such  as  training  material  and  maintenance  aids.  Even 
though  it  is  only  a  de  facto  standard,  it  has  stood  the  test  of 
time  since  its  initial  publication.  However,  it  does  have  some 
technical  limitations,  such  as  the  lack  of  standard  language 
bindings.  CORE  was  developed  around  functional  concepts  that 
included  the  idea  that  internal  structure  and  application  are 
more  important  than  syntax  and  calling  sequence  details.  CORE 
was  submitted  for  ANSI  approval,  but  was  held  up  for  refinements, 
during  the  course  of  which  it  was  overrun  by  GKS.  Some  see  the 
CORE  standard  as  being  "underspecified"  as  compared  to  GKS, 
creating  conformance  problems.  However,  this  may  simply  reflect 
the  greater  attention  paid  to  GKS  since  its  emergence.  CORE 
still  has  a  community  of  loyal,  even  diehard  supporters.  It  is 
used  in  a  number  of  application  programs  and  remains  a  serious 
graphics  standard  candidate,  at  least  for  some  users. 

4. 1.2. 2. 2  GKS .  However,  the  Graphics  Kernel  System  is  the 
current  leading  candidate  for  an  overall  graphics  language 
standard.  GKS's  explicit  links  to  SGML  were  noted  in  Section 
4. 1.2. 1.1.  Standard  bindings  to  other  programming  languages 
(FORTRAN  initially,  followed  by  Ada,  Pascal,  PL/1,  and  even 
Cobol)  are  or  will  be  available,  in  contrast  to  CORE.  Other  GKS 
advantages  include  workstation  definition  (a  nuisance  to  those 
very  rare  single  input/output  device  users,  but  a  small  step 
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toward  device  independence  for  multi-device  users) ,  multiple  view¬ 
ports  for  more  throughput  efficiency,  better  attribute  manage¬ 
ment,  and  a  variety  of  other  technical  characteristics  which  make 
it  more  complete  and  detailed  than  CORE.  Supporters  also  view 
GKS  as  more  highly  specified,  making  conformance  to  the  standard 
easier.  This  is  because  GKS  is  several  years  more  current  than 
CORE,  having  continued  through  a  number  of  versions  at  the  Inter¬ 
national  Standards  Organization  level  while  CORE  remained  at  the 
ANSI  subgroup  level.  At  the  same  time  as  CORE  was  being  develop¬ 
ed  in  the  United  States,  West  Germany  was  pursuing  a  standardiza¬ 
tion  effort  that  became  GKS.  From  its  West  German  originators, 
who  based  their  work  in  part  on  the  1977  first  draft  of  CORE,  GKS 
went  to  ISO,  which  in  turn  proposed  its  acceptance  by  ANSI.  In 
mid-1982,  the  ANSI  subcommittee  that  had  been  "refining"  CORE 
("Super  CORE")  voted  instead  to  support  GKS.  As  much  as  anything 
else,  it  was  this  action  which  created  the  CORE/GKS  political 
controversy.  GKS  is  now  in  the  final  stages  of  approval  at  both 
ANSI  and  ISO  levels.  Although  GKS  is  more  advanced  than  CORE,  it 
is  also  more  complex  to  learn  and  use,  and  requires  greater  hard¬ 
ware  capability.  Nonetheless,  GKS  now  has  broader  industry  back¬ 
ing  than  CORE,  and  is  widely  seen  as  the  preferred  vehicle  for 
most  of  the  graphics  applications  necessary  in  automated  author¬ 
ing.  Its  principal  deficiency,  two-dimensional  vice  three-dimen¬ 
sional  capability,  may  be  overcome  by  a  PHIGS-like  extension  that 
is  currently  under  development  and  will  probably  be  completed 
before  PHIGS  is  approved. 

4. 1.2. 2. 3  VDI  (CGI) .  GKS  is  one  step  closer  to  device  inde¬ 
pendence  than  CORE.  However,  GKS  is  still  basically  a  device 
dependent  application  graphics  language.  VDI,  the  first  draft  of 
which  is  still  being  developed  for  release  in  1985,  is  a  further 
major  step  in  the  direction  of  device  independence.  Unfortunate¬ 
ly,  despite  strong  industry  support,  even  the  experts  aren't  in 
complete  agreement  about  what  VDI  is,  and  what  it  isn't.  Some 
portray  it  as  a  competitor  to  GKS,  although  most  other  analysts 
recognize  it  as  a  complement  to  both  GKS  and  CORE.  In  part,  this 
may  be  due  to  the  fact  that  the  form  of  the  VDI  command  set, 
which  will  be  substantially  less  sophisticated  than  that  of  GKS, 
isn't  fully  settled.  But  in  addition,  VDI  commands  can  be 
applied  directly,  or  they  can  be  manipulated  by  the  GKS,  CORE,  or 
proprietary  graphics  command  set  used  in  the  application  program. 
This  latter  technique  is  the  intended  method  for  using  the  much 
simpler  set  of  VDI  command  primitives  to  provide  the  maximum 
amount  of  "device  independent"  capability.  Even  at  its  best,  VDI 
will  not  be  totally  device  independent,  but  it  will  represent  a 
major  advance  over  GKS  in  this  respect.  Device  dependent  inter¬ 
faces  for  VDI  will  be  smaller  and  simpler  to  write  than  for  GKS, 
and  may  be  incorporated  in  hardware  connectors  at  some  point  in 
time.  Once  the  standard  is  fully  settled  -  several  years  from 
now  -  most  graphics-related  computer  equipment  will  incorporate 
VDI  firmware.  This  will  interface  with  application  programs, 
which  will  generally  use  CORE,  GKS,  or  even  PHIGS  software  for 
graphics  generation  because  of  their  much  greater  capability. 

VDI's  developers  see  this  standard  as  a  vital  complement  to  these 
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or  any  other  proprietary  graphics  language  standards,  since  VDI 
alone  can  only  satisfy  very  simple  graphics  programming  tasks. 

What  experience  (and  time)  alone  will  determine  is  the  extent  to 
which  programmers  will  choose  to  use  CORE/GKS/PHIGS  to  drive  VDI, 
as  intended,  vice  driving  VDI  directly  from  the  application 
program. 

4. 1.2. 2. 4  VDM  ( CGM) .  VDM  is  presently  a  draft  standard,  for 
which  public  review  and  ANSI  approval  is  expected  in  mid-1985. 
Originally  conceived  as  the  device  independent  data  storage/transfer 
counterpart  to  VDI,  it  may  be  finding  itself  overtaken  by  events  even 
before  the  public  review  and  re-drafting  process  for  the  VDM  standard 
is  complete.  There  is  a  degree  of  functional  overlap  between  VDM  and 
NAPLPS,  and  it  is  unclear  at  this  time  whether  both  will  survive.  If 
not,  then  VDM  may  be  the  candidate  more  likely  to  be  discarded,  for 
although  some  of  its  features  are  more  complete,  it  has  a  lesser  range 
of  functions  and  less  popular  support.  VDM  defines  a  VDI-compatible 
and  GKS-compatible ,  compact,  neutral  file  format  for  two-dimensional 
graphics  image  storage.  VDM  is  a  "picture  capture"  standard.  On  the 
other  hand,  the  metafile  included  as  part  of  the  GKS  standard  as  a 
stop-gap  pending  VDM's  availability  provides  an  audit  trail  of  picture 
changes  by  capturing  successive  GKS  calls.  Text  with  a  broad  range  of 
formatting  attributes  can  be  stored  in  concert  VDM  graphics,  but  VDM 
is  neither  designed  nor  intended  for  text  file  handling.  VDM's 
strength  is  its  developmental  association  with  the  principal  graphics 
standards;  its  weakness  is  its  narrow  scope.  Its  primary  application 
may  be  for  permanent  or  temporary  file  storage  in  stand-alone  systems, 
or  for  archiving  of  data  where  on-line  communication  is  not  a  major 
factor.  Here  the  advantages  of  neutral  file  format  would  outweigh  the 
shortcomings  of  VDM's  narrow  scope. 

4. 1.2. 2. 5  NAPLPS.  The  North  American  Presentation  Level 
Protocol  Syntax  is  the  dominant  American  example  of  a  worldwide 
technology  collectively  known  as  videotex,  or  videotext.  (Within 
the  videotex  industry,  a  technical  distinction  is  drawn  between 
two-way  videotex  communication  and  one-way  teletex  communication; 
here,  the  term  videotex  is  used  generically  to  represent  both 
one-way  and  two-way  data  transmission.)  The  original  British 
version,  called  Prestel,  went  into  commercial  operation  in  1979, 
followed  shortly  afterward  by  separate  French,  German/Dutch, 

Canadian,  and  Japanese  formats.  NAPLPS  is  an  outgrowth  of  the 
Canadian  Telidon  system,  via  an  intermediate  AT&T  product  called 
simply  the  Presentation  Level  Protocol.  It  has  deliberately 
sought  Prestel  compatibility  by  defining  low/medium  resolution 
Prestel  mosaics  as  one  of  its  optional  character  sets.  NAPLPS 
also  has  some  characteristics  of  Antiope  (the  French  system),  as 
indeed  all  the  national  systems  have  some  technical  similarities. 
Unfortunately,  there  are  also  significant  differences  among  the 
systems,  and  the  British  -  whose  Prestel  technology  (extended  to 
accommodate  French  system  requirements)  has  been  generally 
endorsed  as  the  European  CEPT,  or  Council  of  European  Postal 
Telegraph,  standard  -  have  been  reluctant  to  accept  NAPLPS,  which 
is  now  an  ANSI  and  Canadian  standard.  Prestel  has  been  intro¬ 
duced  in  the  United  States,  but  has  only  limited  support.  The 


cost  of  translators  for  either  Prestel  or  NAPLPS  is  still  a 
barrier  to  widespread  commercial  use,  and  simpler  ASCII-based 
videotex-like  systems  such  as  Dow  Jones,  CompuServe,  and  the 
Source  lead  the  American  market.  As  translator  costs  decrease, 
and  marketing  efforts  attract  more  potential  users,  NAPLPS  appli¬ 
cations  will  expand,  replacing  or  upgrading  these  systems.  For 
one-way  teletex,  the  British  Prestel  technology  and  a  NAPLPS-com- 
patible  North  American  Broadcast  Teletext  Specification  (NABTS) 
are  competing  for  de  facto  acceptance,  with  NABTS  projected  as 
the  successful  candidate.  Because  NAPLPS  is  an  approved  stan¬ 
dard,  based  on  international  proprietary  and  non-proprietary 
developmental  effort  extending  back  ten  years  or  more,  it  already 
has  sufficient  usage  experience  to  prove  its  technical  capability 
for  handling  both  text  and  graphics  exchange,  even  though  the 
number  of  NAPLPS  implementations  is  still  small.  But  NAPLPS  was 
developed  for  broadcast  communication  applications  (ie,  presenta¬ 
tion  of  graphics  with  incorporated  text).  Its  long-term  utility 
for  file  transfer  of  automated  authoring  system  files  (ie,  trans¬ 
mission  of  text  with  incorporated  graphics)  is  unclear,  although 
there  is  no  inherent  reason  why  NAPLPS,  with  its  ASCII  text 
subset,  should  be  unsuitable  to  this  task.  Some  observers  see 
NAPLPS  as  a  nearly  universal  data  exchange  standard;  others  see 
it  as  a  "device  dependent,"  special  purpose  "version"  of  VDI; 
while  others  view  NAPLPS  as  a  standard  with  no  role  whatever  in 
the  issues  addressed  by  this  paper.  However,  use  of  the  Antiope 
system  as  a  vehicle  for  video  distribution  of  the  French  tele¬ 
phone  directory  suggests  that  NAPLPS  may  have  a  bigger  role  to 
play  in  distribution  of  technical  manuals  than  the  graphics  are 
community  recognizes.  What  may  be  of  greater  concern,  however, 
is  the  long-term  evolution  of  NAPLPS.  A  proposed  world  standard 
is  being  developed,  based  on  the  best  features  of  the  European 
and  American  standards,  as  well  as  the  Japanese  system,  which 
accommodates  Kanji  characters  by  a  raster,  or  alphaphotographic 
approach . 


4.2  System  Integration.  What  has  been  addressed  thus  far 
are  the  variety  of  different  principal  standardization  efforts 
related  to  graphics  and  text  standards.  In  some  cases,  linkages 
among  these  standards  have  been  noted  -  for  example,  the  develop¬ 
mental  history  of  GKS  based  in  part  on  CORE,  the  planned  binding 
between  SGML  and  GKS,  or  the  parallel  development  of  VDI  and  VDM. 
Fundamentally,  however,  the  interfaces  among  these  standards  have 
yet  to  be  addressed  by  industry,  leaving  unanswered  questions 
about  the  ability  of  existing  standards  to  fully  satisfy  DoD 
objectives.  The  interface  between  DIF-formatted  text  files  and 
GenCode/SGML,  via  a  translator,  needs  to  be  developed.  The  IGES/ 
VDM/GKS  interface,  via  a  set  of  translators,  is  just  beginning  to 
be  explored,  and  even  the  intended  linkage  between  VDM  and  GKS  is 
conceptual  rather  than  physical.  Even  when  these  interfaces  are 
defined,  their  initial  implementations  are  likely  to  be  cumber¬ 
some  at  best,  and  additional  conceptual  effort  and  practical 
experimentation  will  be  needed  to  introduce  both  design  efficien¬ 
cy  and  ease  of  use.  Of  course,  these  problems  are  complicated  by 
the  fluid  character  of  the  standards  themselves.  Major  attention 


will  be  needed  to  achieve  vertical  integration  of  those  indivi¬ 
dual  standards  which  hold  the  greatest  potential  for  satisfying 
DoD  objectives. 

4.3  Implementation  Efforts.  Further  complications  are 
introduced  as  users  attempt  to  implement  the  individual  stan¬ 
dards  ,  filling  in  gaps  in  capability  with  system-unique  logic. 

For  example,  GKS  offers  graphics  program  and  data  portability 
between  GKS-based  systems,  but  does  not  assure  data  portability 
to  a  non-GKS  system  because  the  VDI/VDM  standards  are  still  under 
development,  while  a  GKS-compatible  system  with  a  proprietary 
three-dimensional  extension  would  preclude  even  program  portabili 
ty.  Despite  DoD  preference  for  adoption  and  use  of  industry 
(non-government)  standards,  some  form  of  interim  DoD  standards  or 
specifications  may  be  needed  if  near  term  data/program  exchange 
among  the  Military  Departments  and  defense  contractors  is  to  be 
achieved.  Individual  Service  actions  may  introduce  additional 
incompatibility,  particularly  for  interservice  data  exchange. 

For  example,  NAVSEA's  recent  action  in  adopting  IGES  Version  2.0 
for  CAD/CAM  data  exchange  establishes  a  clear  policy  to  be 
followed  for  ship  acquisition  programs,  but  leaves  several  ques¬ 
tions  about  data  compatibility  unanswered.  The  NAVSEA  Instruc¬ 
tion  5230.8  provides  a  phased  implementation  schedule  (June 
1984-December  1985)  for  IGES  Version  2.0  entities  to  be  used  by 
prime  contractors  in  delivering  CAD/CAM  data  to  the  Navy,  encour¬ 
ages  but  does  not  require  use  of  IGES  by  subcontractors  unless 
dealing  directly  with  NAVSEA,  and  recognizes  but  does  not  address 
current  IGES  limitations.  These  problems,  along  with  that  of  the 
government  to  effectively  validate,  store/retrieve,  and  utilize 
this  data,  should  be  addressed  before  DoD  commits  itself  to  a 
major  initiative  with  respect  to  use  of  IGES,  or  any  other 
graphics/text  standard. 

4.4.  Conclusions .  All  of  the  standards  identified  in  this 
paper  have  limitations  of  some  form,  even  NAPLPS  an,*  SGML,  which 
are  the  most  complete.  SGML  (GenCode)  and  IGES  are  widely 
accepted  as  the  standards  of  choice  in  their  respective  areas. 
Questions  and  some  controversy  exist  concerning  the  choice  be¬ 
tween  GKS  and  CORE,  and  between  VDM  and  NAPLPS,  although  GKS  and 
NAPLPS  respectively  appear  to  offer  the  greater  benefits,  as  well 
as  having  the  greater  support.  VDI  will  provide  important  bene¬ 
fits,  and  may  affect  both  the  GKS/CORE  and  VDM/NAPLPS  issues. 
PHIGS  may  represent  a  significant  enhancement  over  both  GKS  and 
CORE,  but  its  development  is  still  too  formative  to  warrant  more 
than  very  supportive  interest.  Only  PMIG,  which  has  little 
attraction  for  automated  authoring  of  technical  documentation, 
and  DIF,  which  is  coming  into  use  in  the  Navy,  can  be  set  aside. 
Despite  its  recent  adoption  by  the  Navy,  DIF  represents  an  inter¬ 
im  solution  to  a  current  (albeit,  very  real)  problem,  not  a  long 
term  mechanism  for  meeting  DoD  objectives.  All  standards  require 
validation  of  both  the  standard  itself  and  the  various  implementa 
tions  of  the  standard.  The  more  sophisticated  and  elaborate  the 
standard,  such  as  IGES,  the  greater  the  validation  problem. 


5.  CONTENT  AND  APPLICATION  OF  STANDARDS.  This  section  addresses 
the  major  characteristics,  content,  advantages,  and  limitations 
of  each  of  the  applicable  standards  surveyed  in  the  preceeding 
sections.  Major  emphasis  is  placed  on  IGES,  which  not  only 
offers  the  greatest  opportunity  to  contribute  to  the  satisfaction 
of  DoD  text/graphics  standard  objectives,  but  where  major 
problems  and  corrective  initiatives  are  needed  and  underway. 

5.1  IGES  Content.  The  IGES  standard  describes  both  the  form 
for  communicating  partial  product  definition  information,  and  the 
type  of  information  to  be  communicated.  The  form  consists  of 
file  format  and  structure  —  record  size,  data  types,  file  sec¬ 
tion  definitions,  field  descriptions  and  sizes  (where  applic¬ 
able),  coding  structure,  etc.  The  unit  of  information  which  IGES 
communicates  is  termed  the  "entity."  The  manner  through  which 
entities  are  hierarchically  grouped  or  associated  with  one 
another  defines  the  product  which  the  IGES  file  specifies. 
Although  the  basic  IGES  file  format  is  relatively  primitive  and 
rigid  (eighty  character  records,  ordered  sections  for  file 
definition  and  locator  coding) ,  considerable  flexibility  and 
expansion  potential  is  offered  by  liberal  use  of  free  formatting 
for  individual  entities,  and  use  of  pointers  for  referencing. 

Each  entity  consists  of  a  fixed-format  directory  entry,  and  a 
free  or  semi-free  format  parameter  data  entry,  which  the  direc¬ 
tory  entry  references.  IGES  entities  are  grouped  within  major 
categories  that  are  each  part  of  the  overall  product  definition. 
These  categories  -  geometry,  annotation,  and  structural  relation¬ 
ships  -  are  not  professed  to  be  exhaustive.  Rather,  like  IGES 
entities  themselves,  they  are  intended  to  be  initial  building 
blocks  to  an  overall  product  definition,  the  complete  content  of 
which  has  not  yet  been  defined.  Nor  are  the  entities  exhaustive 
within  a  category,  or  exhaustive  across  all  products.  For  exam¬ 
ple,  IGES  entities  presently  can  represent  two-  and  three-dimen¬ 
sional  wire  frame  geometry,  but  not  solids.  What  is  important  is 
that  the  IGES  standard  is  generally  extensible,  both  in  form  and 
content,  so  that  future  versions  (including  the  Product  Defini¬ 
tion  Exchange  Standard,  or  PDES,  with  its  major  product  defini¬ 
tion  enhancements)  should  be  largely  upward  compatible,  imposing 
minimum  changes  on  existing  implementations  and  (hopefully) 
translators.  Although  it  is  possible  that  future  elaborations/ 
revisions  of  product  definition  content  may  require  that  IGES  be 
entirely  discarded,  this  possibility  presently  appears  unlikely. 

5.1.1  Product  Definition  Categories.  As  presently  avail¬ 
able,  IGES  supports  significant  portions  of  computer  aided 
design/engineering  capability  for  mechanical  applications.  Its 
entities  are  grouped  into  categories  called  geometry,  annotation, 
and  structure.  The  geometry  category  provides  a  pictorial  des¬ 
cription  of  the  product's  shape  and  topology.  Simple  geometric 
entities  such  as  lines  and  conics,  surface  entities  such  as  the 
tabulated  cylinder,  and  combinations  of  these  entities  linked 
through  supporting  structural  entities  make  up  this  category. 

The  annotation  category  clarifies  the  product's  geometry  through 
entities  that  provide  dimensions  and  tolerances,  notes,  labels. 


centerlines,  etc.  Most  important,  however,  are  entities  in  the 
structure  category,  through  which  entities  in  the  geometry  and 
annotation  categories  are  bound  together  to  form  the  complete 
product.  Structural  entities  specify  logical  relationships  and 
attributes.  Attributes  include  properties,  drawing  viewports, 
line  and  text  font  definitions.  Logical  relationships  include 
associativity  among  other  entities  or  classes  of  entities,  and 
subfigures  which  define  complete  subordinate  products  occurring 
one  or  many  times  within  the  overall  product  definition.  A  macro 
entity  is  also  provided  to  build  new  entities  using  other  basic 
IGES  entities  or  macros. 

5.1.2  Product  Definition  Data  Interface.  From  the 
beginning,  IGES  has  been  described  as  a  product  definition  stan¬ 
dard,  although  its  current  title  -  Graphics  Exchange  -  is  a  more 
accurate  description  of  its  current  actual  content.  The  poten¬ 
tial  importance  of  IGES  as  a  product  definition  standard  lies  in 
the  ability  not  merely  to  exchange  IGES-f ormatted  data  among  CAD 
systems,  but  also  in  the  potential  to  pass  IGES-formatted  data 
from  CAD  to  automated  manufacturing  planning  processes.  Although 
this  can  be  done  now,  the  IGES  data  by  itself  is  still  inade¬ 
quate,  because  it  is  both  incomplete  and  improperly  structured 
for  ADP  processing.  Traditionally,  manufacturing  planning  has 
been  based  on  data  read  from  engineering  drawings  (eg,  part  and 
reference  geometry) ,  data  interpreted  from  the  engineering  draw¬ 
ings  (eg,  part  features,  such  as  flanges  and  cutouts),  separate 
data  listings  (eg,  bills  of  mrterial),  and  various  automated  and 
non-automated  process  planning  tools  for  cost,  schedule,  other 
administrative  control  requirements ,  tool  design,  NC  programming, 
etc.  In  its  present  state  of  development,  IGES  provides  for 
automation  of  a  sophisticated  engineering  drawing;  however,  much 
of  the  non-geometric  data  on  the  drawing  is  passed  using  IGES 
annotation  entities  that  digitize  what  is  more  properly  "human 
readable"  text  than  machine-readable  data.  The  Air  Force's 
Product  Definition  Data  Interface  (PDDI)  project  is  an  effort  to 
prototype  the  solution  to  this  deficiency,  leading  to  expanded 
content  and  applicability  for  an  IGES  which  is  much  more  of  a 
product  definition  standard  than  it  is  at  present,  and  hence  much 
more  valuable  for  satisfying  CALS  objectives. 

5.1.3  PDDI  Product  Scope.  In  line  with  the  remainder  of  the 
Integrated  Computer  Aided  Manufacturing  (ICAM)  program  from  which 
it  originated,  the  PDDI  project  is  looking  at  a  class  of  products 
which  can  be  manufactured  in  an  automated  sheet  metal  shop. 

These  products  are  mechanical  applications  from  the  F-18  wing 
leading  edge  extension  and  trailing  edge  flap,  toward  which  the 
structure  of  IGES  is  presently  oriented,  and  include  sheet  metal 
and  composite  ribs,  plus  sheet  metal  and  composite  skins.  A 
turned  part  created  earlier  for  the  CAM- I  Geometric  Modeling 
Project  is  also  being  used.  Hence,  the  PDDI  project  will  not 
create  a  complete  product  definition  for  all  classes  of  products, 
nor  for  all  manufacturing  processes.  However,  when  complete  in 
mid-1985,  the  PDDI  effort  will  have  defined  and  demonstrated  a 
standard  automated  format  for  a  significant  subset  of  the  product 
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definition  data  required  for  original  manufacture,  and  for  later 
re-manufacture  or  modification.  This  format,  expressed  as  a  new 
class  of  entities,  will  be  incorporated  in  PDES  when  it  is 
released  for  public  comment  in  December  1985  or  early  1986. 
Further,  the  PDDI  definition  is  being  developed  in  a  form  that 
will  facilitate  its  extension  to  other  product  classes  and 
manufacturing  processes.  That  is,  a  clear  distinction  is  being 
developed  between  the  logical  layer  of  PDDI,  in  which  the 
entities  themselves  are  defined,  and  the  physical  layer,  in  which 
the  file  format  and  data  structure  of  the  entities  are  defined. 

5.1.4  Product  Definition  Deficiencies.  As  noted,  a  complete 
product  definition,  encompassing  all  the  data  needed  for  design, 
manufacturing,  provisioning,  and  operational  support  for  all 
products,  will  still  have  to  be  developed.  IGES  as  it  currently 
exists  has  been  designed  to  accommodate  that  portion  of  the  pro¬ 
duct  design  which  could  be  most  fully  and  easily  extracted  from 
existing  computer  aided  design  systems.  Even  this  it  does  incom¬ 
pletely.  Versions  2.0  and  3.0  (the  old  Version  2.1)  improve  and 
extend  IGES  Version  1.0' s  treatment  of  mechanical  application 
design,  and  add  finite  element  modeling  and  preliminary  defini¬ 
tion  of  electronics  printed  wiring  boards.  The  PDDI  state  of  the 
art  survey  of  available  and  emerging  CAD  product  definition  tech¬ 
nologies  for  mechanical  applications  found  that  definition  and 
relationships  of  part  features,  as  well  as  constructive  dimen¬ 
sions  and  tolerances,  are  not  yet  addressed.  Most  non-shape 
related  data  (tolerances,  material,  finish/process  specifica¬ 
tions,  drawing  notes,  part  control)  is  addressed,  but  not  well 
integrated  with  part  geometry.  IGES  reflects  these  CAD  deficien¬ 
cies.  IGES  Version  2.0  is  still  limited  to  wire  frame  and  sur¬ 
face  designs;  it  does  not  encompass  solid  (volume)  modeling  for 
mechanical  applications,  and  lacks  essential  features  needed  for 
the  new  extensions,  such  as  schematic  drawing  transfer  for 
printed  wiring  boards.  Preliminary  work  has  been  done  in  these 
areas,  and  PDES  will  contain  further  improvements  together  with 
the  PDDI  proposals.  However,  the  PPES  standard  is  basically 
being  built  around  two  major  extensions  to  IGES:  the  PDDI  pro¬ 
ject,  and  CAM-I's  Experimental  Solids  Proposal  that  deals  with 
both  boundary  representation  and  constructive  solid  geometry. 
Areas  such  as  cabling  and  harness  specifications,  integrated 
circuits  and  printed  circuit  boards,  architectural  engineering, 
plant  and  facility  design,  and  manufacturing  processes  require 
much  more  work.  Proprietary  CAD  systems  are  far  ahead  of  IGES  in 
these  areas.  However,  even  for  mechanical  applications,  there 
are  some  technologies  (such  as  constructive  dimensioning  and 
tolerancing)  which  are  still  in  the  preliminary  development  stage 
Others  (such  as  homogeneous  parametric  forms  for  system-internal 
geometry  representation)  are  steadily  evolving,  so  that  current 
techniques  may  become  obsolete  as  more  efficient  approaches  are 
developed.  Transmission  of  other  "product  def inition"-related 
data,  such  as  R&M  parameters  or  provisioning  data  (or  any 
MIL-STD-1388-2A  data) ,  has  until  recently  been  only  a  suggestion 
for  future  consideration.  (Based  on  discussion  with  the  PDDI 
contractor,  it  appears  possible  to  initiate  a  PDDI  extension  that 


would  incorporate  some  logistics  data,  such  as  provisioning  tech¬ 
nical  data  as  part  of  the  bill  of  materials  definition,  in  PDES.) 
This  means  that  completely  incorporating  such  factors  in  IGES 
could  be  three  to  four  years  away,  even  with  the  DoD  funding 
increases  that  could  expedite  development. 

5.1.5  IGES  Translators.  Because  it  is  not  a  CAD  language, 
IGES  as  a  stand-alone  product  is  useless;  its  utility  depends  on 
the  availability  and  quality  of  translators  from  each  unique  CAD 
system  to  IGES  (pre-processors)  and  from  IGES  to  each  unique  CAD 
system  (post-processors).  These  "indirect"  translators  serve  the 
dual  purpose  of  reducing  the  magnitude  (time  and  resource  invest- 
investment)  of  the  translator  development  burden,  and  preserving 
the  security  of  proprietary  CAD/CAM  software.  However,  a  one-to- 
one  mapping  between  IGES  entities  and  those  of  the  unique  CAD/CAM 
software  is  extremely  difficult,  and  the  decision  rules  for  deal¬ 
ing  with  mapping  options  (one  to  many,  one  to  null,  many  to  one, 
many  to  null)  are  critical.  Even  with  one-to-one  mapping,  the 
translation  can  cause  loss  of  functionality,  so  that  the  eventual 
system-unique  output  entity  cannot  be  used  or  manipulated  in  the 
same  way  as  the  original  input  entity.  Hence  the  significance  of 
translator  validation.  Over  a  dozen  CAD/CAM  vendors,  including 
most  of  the  major  manufacturers,  have  demonstrated  IGES  transla¬ 
tors.  However,  a  recent  study  undertaken  as  part  of  the  PDDI 
project  confirmed  findings  by  others  that  IGES  translators  are 
less  adequate  than  expected.  Problems  include  quality  of  trans¬ 
lation,  subsetting  of  the  IGES  standard  or  variations  among  ver¬ 
sions  of  IGES,  and  operational  or  conceptual  differences  between 
sending  and  receiving  CAD  systems.  The  tests  were  themselves 
less  than  complete;  the  PDDI  survey,  for  example,  was  largely 
based  on  the  original  IGES  Version  1.0,  not  the  more  current 
Version  2.0,  that  has  been  available  in  draft  for  about  two 
years,  or  the  new  Version  3.0,  that  is  nearing  technical  comple¬ 
tion.  Consequently,  much  work  remains  to  assure  that  IGES  -  even 
to  the  extent  to  which  it  is  presently  developed  -  can  be  confi¬ 
dently  used  for  CAD/CAM  weapon  system  data  exchange,  especially 
where  a  significant  DoD  application  involves  archiving  data  for 
post  production  support  years  after  the  original  design  team  has 
been  disbanded.  Again,  funding  is  a  significant  constraint,  for 
development  of  test  data  and  physical  review  of  translated  files 
are  time  consuming  and  extremely  labor  intensive. 

5.1.6  IGES  Data  Requirements.  Although  DoD  objectives  for 
transmission  and  storage  of  CAD/CAM  data  can  be  best  satisfied  by 
availability  of  a  complete  IGES  standard  (including  logistics 
data)  and  fully  validated  translators  for  at  least  the  major 
vendor  systems,  it  remains  unclear  what  subset  of  this  ambitious 
goal  is  sufficient  for  the  near  term.  The  same  PDDI  study  which 
questioned  the  adequacy  of  IGES  translators,  found  that  IGES 
provided  largely  adequate  representation  of  the  class  of  CAD 
drawings  that  were  tested.  However,  this  only  touches  on  poten¬ 
tial  IGES  requirements  for  drawing  repositories,  configuration 
management,  post  production  support,  etc.,  as  they  apply  to  inte- 
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grated  circuits  and  other  product  classes  not  yet  incorporated  in 
IGES. 


5.2  Graphics  Kernel  System.  GKS  provides  a  set  of  185 
different  functions,  some  of  which  are  complex,  even  though  they 
are  very  powerful.  For  example,  coordinate  transformation  for 
output  to  a  display  device  can  be  a  four-step  process,  sometimes 
requiring  the  programmer  to  choose  between  trial-and-error  and  a 
pocket  calculator  for  translating  application  coordinates  (the 
computed  or  observed  values  to  be  plotted)  to  world  coordinates 
(the  Cartesian  scale  that  may  or  may  not  be  the  same  as  the  appli¬ 
cation  coordinates),  for  which  an  application  program  routine  may 
need  to  be  developed,  to  normalized  device  coordinates  (a  part  of 
the  lxl  GKS  unit  screen  onto  which  a  part  of  the  world  coordinate 
display  is  mapped),  for  which  the  programmer  must  define  both  SET 
WINDOW  and  SET  VIEWPORT  limits  so  that  GKS's  normalization  trans¬ 
form  routine  can  accomplish  the  actual  translation,  to  physical 
device  coordinates  (the  physical  resolution  of  the  hardware 
display  device) ,  which  the  hardware-dependent  graphics  device 
driver  handles  automatically  once  the  programmer  has  provided 
composition  layout  for  his  graphic  art,  tables,  and  text.  GKS's 
solution  to  the  complexity  problem  -  the  opposite  of  that  taken 
by  the  designers  of  Ada  -  is  to  encourage  language  subsets.  By 
discouraging  subsets,  Ada  delayed  implementation  but  facilitated 
full  program  transportability  when  implementation  occurred;  by 
encouraging  subsets,  GKS  has  facilitated  (both  eased  and  speeded) 
implementation,  but  decreased  transportability  potential.  More¬ 
over,  even  the  "M"  (minimum-level)  subset  requires  so  much 
in-memory  storage  that  few  8-bit  microprocessor  applications  are 
likely.  On  the  other  hand,  the  complete  GKS  function  set  (level 
2b,  or  the  more  operating  system-dependent  level  2c)  offers  exten¬ 
sive  capability.  A  particulary  useful  feature  -  though  also  an 
impediment  to  transportability  -  is  its  generalized  drawing  primi¬ 
tive,  which  allows  escape  from  GKS  to  the  proprietary  graphics 
commands  offered  by  the  host  software  system.  For  example,  GKS 
has  no  "CIRCLE"  command.  A  circle  can  be  drawn  in  GKS  either  by 
loading  the  circle  point  values  into  one  or  more  arrays  and  then 
using  a  GKS  "POLYLINE"  command,  or  more  simply  by  using  a  general¬ 
ized  drawing  primitive  that  employs  a  host  software  "CIRCLE" 
command  to  automatically  convert  center  coordinate  and  radius 
values  into  the  required  boundary  points.  (A  "registry"  of 
generalized  drawing  primitives  will  partially  standardize  these 
calls,  enhancing  transportability  to  those  systems  that  choose  to 
support  the  registered  calls.)  Another  valuable  GKS  feature  is  a 
strong  set  of  inquiry  function  to  check  and  return  device  status 
for  controlling  the  application  program. 

5.2.1  Workstation  and  Bundling  Control.  Although  GKS  is  not 
device  independent  in  the  same  way  that  VDI  will  be,  much  work 
has  gone  into  defining  powerful,  albeit  sometimes  complicated, 
techniques  that  make  GKS  programs  highly  independent  from  the 
form  of  the  physical  device  used  for  output.  One  technique  used 
to  accomplish  this  is  through  the  conceptual  abstract  of  a  "work¬ 
station,"  which  programmatically  defines  the  characteristics  of 
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one  or  more  output  devices  to  which  GKS  graphics  can  be  driven. 

For  example,  in  a  simple  monochrome  system  with  a  terminal  and 
plotter,  workstation  one  might  be  defined  to  generate  white  lines 
on  a  black  background  (the  terminal),  and  workstation  two  to 
generate  black  lines  on  a  white  background  (the  plotter).  The 
same  POLYLINE  command  would  drive  each  workstation  according  to 
its  predefined  characteristics.  A  more  sophisticated  program 
would  use  a  workstation  bundle  table  to  set  color  index,  line 
type  and  width,  and  other  attributes  for  each  physical  output 
device  associated  with  the  particular  system  on  which  the  GKS 
graphics  program  was  developed.  When  that  program  is  moved  to 
another  system,  the  workstation  definitions  could  be  easily 
changed  without  disturbing  the  remainder  of  the  program.  Attri¬ 
butes  which  are  common  to  all  workstations  can  still  be  set  indi¬ 
vidually  (ie,  unbundled). 

5.2.2  Segmentation .  One  of  GKS's  most  powerful  capabilities 
is  segmentation,  which  provides  a  graphics  tool  similar  to  a 
programming  language  subroutine.  This  allows  graphic  images  to 
be  built  up  from  simpler  GKS  primitives  and  then  manipulated  by 
single  transformation  commands  which  rotate,  highlight,  or  color 
the  entire  segment.  This  capability  is  important  for  any  appli¬ 
cation,  including  technical  document  illustration,  but  offers 
particular  potential  for  terminal  display  of  training  material  or 
maintenance  aids.  However,  GKS  does  not  allow  nesting  (or  hier¬ 
archies)  of  segments,  as  will  be  possible  with  PHIGS  structures. 

5.2.3  GKS  Deficiencies.  In  the  confrontational  warfare 
between  GKS  and  CORE,  GKS  has  principally  been  criticized  for  its 
lack  of  three-dimensional  capability  and  its  complexity.  Whether 
the  former  represents  a  critical  deficiency  for  CALS  applications 
(such  as  interactive  training)  is  unclear.  Complexity  does 
represent  a  problem  (which  GKS  supporters  minimize) ,  particularly 
when  subsetting  is  encouraged,  but  in  return  offers  functional 
flexibility  that  has  made  GKS  the  preferred  standard  among  indus¬ 
try  users  of  graphics.  Once  bindings  to  SGML  and  a  range  of 
programming  languages  are  in  place,  GKS  applications  will  proli¬ 
ferate.  A  pre-PHIGS  three-dimensional  extension  to  GKS  is  being 
developed,  and  device  independence  will  be  enhanced  through  inter¬ 
faces  with  VDI  and  VDM.  GKS  provides  its  own  metafile  construct, 
and  the  input/output  functions  to  access  such  a  file,  but  not  a 
standardized  data  storage  format.  Other  technical  shortcomings 
(such  as  a  cell  array  primitive  for  storing  raster  "pixelated 
image"  graphics,  that  lacks  an  independent  attribute  list  and 
multiple  image  capability,  or  multiple  sets  of  lookup  tables)  can 
be  corrected  by  future  extensions. 

5.3  CORE.  Despite  the  comparison  between  complex  GKS  and 
simple  CORE,  these  two  graphics  standards  actually  have  much  in 
common.  CORE  is  the  earlier  standard,  and  its  published  draft 
in  1977  provided  major  input  to  the  construction  of  GKS. 

Although  there  are  other  technical  variations,  the  principal 
differences  between  CORE  and  GKS  arise  from  the  deliberate  effort 
to  increase  the  flexibility  of  GKS  graphics.  CORE  lacks  the 


concepts  of  workstations,  attribute  bundling,  and  multiple  view¬ 
ports.  Also,  CORE  uses  a  "pen  movement"  concept  and  relative 
positioning,  in  which  the  results  of  output  primitives  (commands) 
may  depend  on  the  results  of  previous  commands.  GKS,  on  the 
other  hand,  is  designed  so  that  each  command  can  be  independent 
of  all  preceeding  commands.  Lack  of  standard  bindings,  such  as 
GKS  does/will  offer,  is  an  inhibitor  to  usage  of  CORE,  although 
not  an  absolute  constraint;  there  are  numerous  CORE  or  CORE-like 
applications  which  have  built  up  a  small  but  intensely  loyal 
community  of  support  for  this  de  facto  standard.  CORE  also  faces 
transportability  problems  because  of  the  workstation/bundling 
deficiency,  and  partly  because  -  like  GKS  -  CORE  encourages  sub- 
setting  . 


5.3.1  Three-Dimensionality.  In  the  final  analysis,  it  is 
the  issue  of  three-dimensionality  that  maintains  CORE  as  a  viable 
potential  candidate  for  an  industry-wide  graphics  standard,  and 
as  a  potential  satisfier  of  CALS  objectives.  Pending  development 
of  a  standard  three-dimensional  extension,  GKS  can  simulate  three 
dimensions  in  the  same  manner  that  an  artist  simulates  three 
dimensions  on  a  flat  surface,  but  only  by  adding  commands  to  the 
program  that  fix  the  viewing  perspective.  This  is  because  GKS 
was  designed  to  be  only  a  two-dimensional  graphics  standard.  On 
the  other  hand,  CORE  offers  a  true  three-dimensional  capability. 
With  CORE,  the  graphic  can  be  generated  in  a  three-dimensional 
volume  that  is  integrated  with  the  viewing  transformation,  and 
mapped  into  a  three-dimensional  normalized  device  space.  This 
can  be  displayed  directly  on  a  device  that  supports  three  dimen¬ 
sions,  or  transformed  again  for  output  on  a  two-dimensional 
display  device.  This  final  transformation  can  either  eliminate 
the  third  axis  entirely,  or  angle  it,  as  a  flat  surface  artist 
would  do.  Although  CORE'S  three-dimensionality  may  offer  some 
advantages  for  illustration  of  technical  publications  (particu¬ 
larly  in  an  integrated  system  where  graphics  are  built  from  a 
three-dimensional  IGES  source  data  file),  it  appears  that  for 
most  technical  illustration  purposes,  GKS's  greater  flexibility 
and  slightly  greater  device  independence  offers  more  functional 
benefit  than  CORE.  However,  this  may  not  be  true  in  the  case  of 
interactive  training  material  and  maintenance  aids  displayed 
on-screen.  Here  there  are  obvious  advantages  to  three-dimension¬ 
ality,  particularly  if  the  viewing  angle  and  perspective  can  be 
user-controlled.  For  this  reason,  CORE  cannot  simply  be 
dismissed  from  consideration,  at  least  until  a  non-proprietary 
three-dimensional  extension  to  GKS  is  available. 

5.4  Programmer's  Hierarchical  Interactive  Graphics  Standard. 
The  development  of  PHIGS,  for  which  an  initial  draft  is  now  being 
completed,  is  intended  to  remedy  the  principal  shortcomings  of 
both  CORE  and  GKS.  It  is  too  soon  to  determine  whether  it  will 
be  successful  in  meeting  this  objective,  or  in  supporting  CAD/CAM 
graphics  requirements.  PHIGS'  developers  address,  but  do  not 
stress,  its  potential  CAD/CAM  role,  and  are  discretely  cautious 
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about  the  extent  to  which  PHIGS  will  subsume  GKS  applications 
outside  the  CAD/CAM  world.  PHIGS  will  offer  three-dimensionali¬ 
ty,  and  a  multi-level  segmentation  (structures)  hierarchy,  with 
lower  memory  overhead  and  faster  response  time.  Although  PHIGS 
represents  an  evolutionary  advance  in  graphics  languages,  it  will 
not  be  fully  upward  compatible  with  either  CORE  or  GKS.  PHIGS 
structures  consist  of  an  ordered  list  of  elements,  in  which 
attributes  are  applied  to  graphics  primitives  as  the  (nested) 
hierarchy  is  traversed.  On  the  other  hand,  in  GKS'  single-level 
segments  the  attributes  are  applied  as  the  primitive  is  initially 
defined,  and  the  segment  list  itself  is  an  unordered  collection. 
The  transformation  pipeline  -  from  a  modeling  coordinate  system 
to  a  world  coordinate  system  via  a  composite  modeling  transforma¬ 
tion,  to  a  viewing  coordinate  system  via  a  viewing  transforma¬ 
tion,  to  a  normalized  projection  coordinate  system  via  a  clipping 
and  view-mapping  transformation,  to  a  device  coordinate  system 
via  a  workstation  transformation  -  is  longer  but  is  handled  more 
efficiently  than  in  GKS.  However,  VDI  and  VDM  interfaces  with 
PHIGS  will  be  very  similar  to  those  with  GKS.  Clearer  definition 
of  DoD  requirements  for  a  graphics  language  standard,  based  on 
test  applications  of  CORE  and  GKS,  would  facilitate  directing 
PHIGS  development  toward  CALS  objectives.  At  the  present  time, 
however,  significant  active  DoD  participation  in  the  PHIGS 
development  effort  would  provide  limited  benefit. 

5.5  Virtual  Device  Interface.  GKS,  CORE,  and  PHIGS  all  have 
a  high  degree  of  device  dependence,  even  though  concepts  such  as 
workstation  definition  facilitate  program  portability.  VDI  (CGI) 
will  address  this  problem  by  providing  a  major  device  independent 
segment  coupled  with  a  small  set  of  device  dependent  drivers, 
which  may  someday  be  incorporated  on  a  peripheral  or  host  hard¬ 
ware  connector.  The  device  independent  portion  of  VDI  will 
provide  a  set  of  command  primitives  similar  to  (but  simpler  than) 
those  provided  by  GKS;  hence,  simple  graphics  could  be  developed 
using  VDI  alone  in  a  program  that  would  operate  faster  than  the 
same  program  written  using  the  higher-order  GKS  language.  VDI 
also  encourages  subsetting,  with  classes  of  required  and  optional 
functions,  and  an  inquiry  capability  to  identify  a  particular 
device's  incorporated  function  subset.  However,  few  graphics 
programs  will  actually  be  written  with  VDI  alone,  because  of  its 
intentional  language  limitations  (eg,  the  absence  of  segmentation 
and  viewport  manipulation).  DoD's  principal  concern  with  VDI, 
the  draft  of  which  is  being  prepared  for  initial  review  in  1985, 
should  be  the  extent  and  manner  of  interfacing  a  higher  level 
graphics  language  such  as  GKS  with  VDI,  as  well  as  the  potential 
problems  associated  with  development  of  VDI  device  drivers. 

5.6  North  American  Presentation  Level  Protocol  Syntax. 

NAPLPS  is  a  neutral  data  exchange  format  for  graphics  and 
supporting  text  that  may  provide  a  vehicle  for  transmission/ 
presentation  of  digitized  technical  documentation  used  for 
training  or  maintenance  aids,  especially  in  a  static  (non-inter 
active)  environment.  Since  ASCII  is  a  subset  of  NAPLPS,  even 
SGML-coded  text  could  be  transmitted  as  NAPLPS-compatible  data. 


Like  IGES,  NAPLPS  is  a  device  independent  standard  requiring 
system-unique  translators.  And,  like  IGES,  it  has  widespread 
user  support.  There,  most  of  the  similarity  ends.  Despite  some 
troublesome  deficiencies  and  ambiguities  (discussed  in  paragraph 
5.6.2),  NAPLPS  is  a  nearly  complete  standard.  Through  its  over¬ 
lay  structure  of  control  sets  and  graphics  sets,  it  provides 
almost  total  representation  of  text  and  graphics  data,  including 
user-definable  commands.  This  same  structure  makes  it  easily 
extensible  to  new  classes  of  entities,  such  as  the  widely-desired 
addition  of  sound  and  speech  representation,  or  the  T-code  (tele¬ 
software)  proposal  now  being  considered  by  ANSI,  without  loss  of 
compatibility.  Because  it  was  specifically  designed  for  trans¬ 
mission  efficiency  within  the  Videotex  market,  with  its  band 
width  limitations,  NAPLPS  was  designed  to  produce  extremely 
compact  code.  On  the  other  hand,  IGES  was  designed  functionally 
for  optimum  support  of  its  entity  command  structure,  and  is 
extremely  voluminous  even  in  binary  transmission  format.  (Human 
readability  of  the  IGES  file  was  described  as  one  of  the  advan¬ 
tages  of  ASCII-formatted  IGES  Version  1.0.)  NAPLPS  translators 
do  not  face  quite  the  same  magnitude  of  validation  problems  that 
IGES  translators  must  contend  with,  because  NAPLPS  command  primi¬ 
tives  in  the  Picture-Description  Instruction  Set  are  much  more 
simplistic  than  most  IGES  entities.  The  Canadian  government  has 
already  developed  a  semi-official  set  of  test  data,  and  NBS  is 
working  with  the  Canadian  Department  of  Communications  to  improve 
this  test  data  and  develop  an  automated  testing  facility.  The 
principal  translator  problem  NAPLPS  faces  is  the  tendency  of 
vendors  to  implement  translator  subsets  as  NAPLPS  use  gradually 
expands  into  lower-cost,  limited  capability  hardware  applications. 
Another  problem  -  which  more  widespread  use  of  NAPLPS  will  help 
to  resolve  -  translator  incompatibility  in  the  handling  of  text 
data.  The  seven-bit  and  eight-bit  versions  of  NAPLPS  do  have 
slightly  different  coding  conventions,  but  this  is  not  considered 
a  major  problem.  More  significantly,  NAPLPS  is  only  a  presenta¬ 
tion-level  standard;  it  includes  neither  session  level  rules  (to 
handle  switching  between  seven-bit  and  eight-bit  modes,  for 
example),  nor  application  level  rules  (to  control  neutral  format 
file  storage  and  retrieval) .  A  bit  stream  of  NAPLPS  data  can  be 
passed  between  two  systems,  assuming  both  have  the  necessary 
session-level  decoders,  but  a  NAPLPS  file  created  by  one  system 
may  not  be  directly  legible  by  the  other  system.  On  the  other 
hand,  IGES  is  defined  as  a  file  structure,  with  record  structure 
and  ordering  for  ease  of  handling.  A  NAPLPS  file  could  be  trans¬ 
lated  for  storage  '.n  VDM  format,  although  it  is  not  clear  how 
difficult  or  cumbersome  this  would  be. 

5.6.1  NAPLPS  Structure.  The  main  feature  of  NAPLPS  is  its 
overlay  structure,  which  facilitates  extensibility.  The  128-ele- 
ment  character  codes  for  seven-bit  NAPLPS,  or  the  two  sets  of 
128-element  characters  for  eight-bit  NAPLPS,  are  partitioned  into 
control  sets  and  graphics  sets,  each  of  which  is  intended  to  be 
re-defined  under  user  control.  Hence,  to  extend  NAPLPS  for  sound 
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generation  would  merely  involve  establishing  another  set  of  defi¬ 
nitions  for  the  user  to  invoke.  The  control  sets  provide  trans¬ 
mission  or  terminal  control,  identify  the  in-use  graphics  set, 
define  macros,  etc.  The  graphics  sets  provide  text  character 
definitions,  picture  descriptor  instructions  or  drawing  primi¬ 
tives,  Prestel-compatible  mosaics,  macros,  and  user-definable 
characters  or  fonts.  Seven-bit  NAPLPS  uses  shift-in/shift-out 
op  codes  to  exchange  graphics  sets.  Eight-bit  NAPLPS  uses  the 
eighth  bit  to  represent  the  graphics  set  directly,  saving  both 
storage  space  and  transmission  time.  However,  seven-bit  NAPLPS 
is  the  more  common  implementation,  since  the  current  principal 
NAPLPS  applications  operate  over  voice  grade  telephone  lines, 
using  asynchronous  seven-bit  transmissions.  After  its  overlay 
coding  structure,  the  next  most  important  feature  of  NAPLPS  is 
its  resolution  and  color  independence.  NAPLPS  uses  a  bit-mapped 
virtual  screen,  and  coordinate  system,  in  which  positions  are 
specified  in  fractions  of  a  lxl  unit  screen.  Each  coordinate 
byte  specifies  a  three-bit  x-axis  fraction  and  a  three-bit  y-axis 
fraction.  Precision  is  increased  by  adding  a  second  (or  greater) 
coordinate  byte.  The  NAPLPS  translator  applies  the  transmitted 
coordinate  fractions  to  whatever  pixel  resolution  is  provided  by 
the  display  hardware.  Color  resolution  is  achieved  by  a  similar 
technique  of  increasing  or  decreasing  the  depth  of  the  bit  plane 
with  one  or  more  bytes  of  data.  (Raster  graphics  also  generally 
uses  a  multiple  bit  plane,  but  NAPLPS  offet  a  more  powerful 
capability  by  indexing  color  coordinates  to  a  color  table,  rather 
than  specifying  them  absolutely.)  The  maximum  display  and  color 
resolution  possible  with  NAPLPS  far  exceeds  current  practical 
hardware  capability;  most  current  translators  and  development 
software  do  not  bother  to  even  attempt  implementing  this  full 
capability.  Graphics  using  the  NAPLPS  drawing  primitives  employ 
either  absolute  or  relative  positioning,  incremental  (chain) 
encoding  for  compact  storage  of  irregular  line  shapes,  indepen¬ 
dent  positioning  of  drawing  point  and  text  cursor,  and  user  defi¬ 
nition  of  drawing  attributes  such  as  stroke  width  and  texture. 
Macros  can  be  nested,  although  NAPLPS  does  not  (yet)  provide  the 
features  of  a  true  programming  language  such  as  DO  loops  and 
conditionals.  Translators  can  tailor  NAPLPS  implementation  to 
suit  user  needs,  such  as  size  of  macro  storage,  and  pre-cutting 
(fast,  but  resolution  constrained)  or  on-call  cutting  (slower, 
but  more  precise  and  compact)  of  user-defined  character  tem¬ 
plates  . 

5.6.2  Shortcomings  of  NAPLPS.  NAPLPS  has  several  content 
deficiencies,  most  of  which  could  be  remedied  through  appropriate 
extensions,  and  some  of  which  (such  as  data  storage  and  retrie¬ 
val)  are  remedied  through  application  level  programming. 

Although  NAPLPS  is  intended  to  be  used  for  on-line,  real  time 
data  transfer,  its  design  reflects  a  batch  mode,  sequential 
processing  mind  set.  Animation  in  NAPLPS  is  often  called  "blink 
animation,"  because  each  frame  is  built  stepwise  and  is  destruc¬ 
tive  of  the  previous  contents  of  the  video  map;  to  show  movement, 
an  entire  frame  must  be  re-transmi tted  and  re-translated ,  which 


can  be  very  slow,  even  for  terminals  operating  at  high  clock 
speed.  NAPLPS  provides  for  user  definition  of  macros,  which  are 
transmitted  only  once,  stored  in  a  holding  area  outside  the  video 
map,  and  called  at  will.  But  there  is  no  corresponding  stack 
storage  to  hold  and  recall  attributes  which  may  be  temporarily 
changed  when  the  macro  is  invoked.  For  text,  there  is  no  stan¬ 
dard  character  font  definition,  and  although  NAPLPS  allows  for 
proportional  spacing  of  text,  there  is  no  standard  proportion¬ 
ality  algorithm.  Hence,  a  line  breakpoint  as  computed  by  one 
translator  may  be  different  than  that  computed  by  another. 

Although  NAPLPS  handles  both  text  and  graphics  transmission,  its 
principal  text  application  is  for  graphic  (ie,  visual)  display  of 
formatted  text,  not  document  processing  in  the  sense  for  which  a 
language  like  GenCode  is  used.  It  also  lacks  a  standard  roundoff 
algorithm,  which  can  affect  proportionality  and  relative  position 
calculations  for  low-resolution  display  of  graphics  created  using 
high-resolution  precision. 

5.7  Virtual  Device  Metafile.  VDM  (CGM)  provides  a  neutral 
file  storage  and  transmission  counterpart  to  the  VDI  device 
independent  graphics  language.  Hence,  it  satisfies  a  deficiency 
in  NAPLPS  -  that  is,  a  device  independent  file  storage  structure 
-  while  at  the  same  time  providing  VDI  and  GKS  compatibility.  As 
with  other  so-called  "device  independent"  standards,  VDM  requires 
system/language  unique  translators  that  write  to,  and  read  from 
the  neutral,  transportable  VDM  file.  The  VDM  standard  describes 
seven  classes  of  data,  which  provide  file  descriptors  and 
defaults;  picture  controls,  format  descriptions,  and  attribute 
interpretation  modes;  drawing  primitives  and  attributes;  device 
and  system  escapes;  and  non-graphic  message/text  and  other  data. 
VDM's  text  handling  capability  provides  better  user  control  than 
NAPLPS,  but  VDM  remains  primarily  a  graphics  file  standard.  Data 
can  be  stored  in  a  VDM  file  in  clear  text,  character  encoded,  or 
binary  form,  providing  a  range  between  human-readable  but  volu¬ 
minous,  and  very  compact  storage.  Although  these  features  offer 
an  advantage  over  NAPLPS,  the  latter's  proven  utility,  and  hence 
its  broader  support,  make  VDM's  future  unclear.  Except  for  file 
structure  standardization  and  GKS  compatibility,  just  about  every¬ 
thing  VDM  does  can  be  done  as  well  by  NAPLPS.  VDM  will  have  to 
prove  itself  in  the  marketplace;  DoD  can  influence  that  decision, 
but  lacks  adequate  information  to  express  a  preference  at  this 
point  in  time.  DoD  should  support  further  development  and  demon¬ 
stration  of  both  standards  until  the  strengths  and  weaknesses  of 
each  for  defense  applications  have  been  explored. 

5.8  SGML/GenCode  Structure.  The  SGML  standard  defines  a 
text  processing  language  which  would  be  used  to  implement  a 
generic  document  coding  structure.  The  generic  coding  structure, 
which  has  been  trademarked  as  GenCode,  is  the  conceptual  heart  of 
SGML.  The  accompanying  text  processing  language  is  the  recom¬ 
mended  technique  for  efficient  implementation  of  GenCode,  but 
GenCode  can  be  implemented  on  most  vendor-unique  text  processing 
systems,  through  the  use  of  specialized  translators.  GenCode 


(or,  more  properly,  the  document  markup  metalanguage)  is  techni¬ 
cally  independent  of  its  implementation,  and  a  system  can  be 
"SGML  compatible"  if  it  employs  the  markup  metalanguage  of  SGML/ 
GenCode,  but  not  the  remainder  of  the  standard  SGML  text  process¬ 
ing  language.  GenCode  identifies  the  textual  elements  and  hier¬ 
archical  structure  of  the  document  through  a  set  of  user-custom¬ 
ized  codes,  called  generic  identifiers,  which  follow  specified 
rules  of  grammar.  These  codes  can  then  be  used  to  invoke  output 
formatting  tables  which  are  applied  by  the  text  processing 
language  to  translate  the  marked-up  document  into  a  specific  form 
for  a  particular  output  application  -  for  example,  changing  type 
fonts,  page  margins,  placement  of  footnotes,  or  indentation  rules. 
Under  the  SGML/GenCode  concept,  a  document  consists  of  blocks  of 
data  separated  by  the  appropriate  markup  codes.  This  facilitates 
the  incorporation  of  graphics  or  other  "non-standard"  data  into  a 
mixed  mode  document  by  using  special  markup  codes  that  open  and 
close  the  non-standard  sections.  The  SGML  text  processing 
language  must  provide  the  GKS  bindings  that  would  facilitate  the 
creation  of  graphics  data  to  be  included  in  these  non-  standard 
sections.  The  text  processing  language  in  the  SGML  standard  is 
specifically  intended  to  provide  these  bindings.  However,  the 
SGML  standard  does  not  specify  the  physical  structure  in  which 
the  document  is  stored  or  transmitted. 

5.8.1  SGML/GenCode  Application.  The  markup  metalanguage, 
whether  it  is  called  SGML  or  GenCode,  is  comprehensive  yet  flex¬ 
ible;  it  can  be  tailored  to  specific  applications,  and  is  already 
in  use  within  DoD  for  preparation  of  technical  documentation. 

Users  report  that  it  provides  more  than  enough  capability  for 
this  application.  Some  users  find  it  slightly  difficult  to  use 
because  its  "raw  data"  form  lacks  the  familiar  page  image  format 
of  WYSIWYG  (what  you  see  is  what  you  get).  Some  users  report 
success  in  using  standard  word  processing  equipment  for  "quick 
and  dirty"  text  keyboarding  without  SGML  tags.  Word  processing 
control  codes  are  software-stripped,  after  which  tagging  is  done 
by  a  small  group  of  SGML  specialists.  In  this  way,  volume  input 
of  technical  documentation  can  be  accomplished  quickly,  easily, 
and  less  expensively.  Certain  applications  are  probably  less 
appropriate,  however;  an  example  would  be  an  on-line,  interactive 
training  system  where  text  presentation  is  highly  dependent  on 
the  processing  language  itself.  Even  here,  GenCode  would  provide 
a  system- independent  method  for  initial  creation  of  the  training 
material  itself,  prior  to  its  incorporation  in  the  particular 
output  application  (the  training  system).  Once  transferred  to 
the  output  application,  the  text  data  segments  delineated  by 
generic  markup  codes  would  be  completely  reorganized  for  storage 
in  the  training  system’s  knowledge  base. 

5.9  Problems  in  Graphics  and  Text  Merger.  The  preceding 
paragraphs  have  focused  on  the  strengths  and  weaknesses  of  indi¬ 
vidual  standards,  as  well  as  comparisons  between  those  which 
accomplish  the  same  or  similar  functions.  An  equally  significant 


problem,  with  a  very  limited  experience  base  and  numerous 
unknowns,  is  the  use  of  several  complementary  standards  to  merge 
CAD/CAM  graphics  and  text  data  into  a  single  technical  document. 
These  issues  can  be  illustrated  by  example.  This  simple  hypo¬ 
thetical  example  involves  producing  a  technical  document  consist¬ 
ing  of  a  narrative  discussion  of  a  product,  illustrated  with  line 
art  from  the  CAD  design  of  the  product,  and  supplemented  by  a 
parts  list  sorted  and  formatted  in  non-standard  form.  The  follow¬ 
ing  sections  point  out  some  of  the  questions  implicit  in  attempt¬ 
ing  to  apply  these  graphics  and  text  standards  to  this  example. 

5.9.1  SGML/GenCode .  The  essential  problem  is  that  of 
integrating  graphics  data  into  the  text  stream.  SGML  simplifies 
this  problem  by  providing  the  capability  for  mixed-mode  assembly 
of  text  and  graphics  into  a  single  data  stream.  However,  if  any 
of  the  narrative  is  extracted  from  text  entered  directly  into  a 
CAD  workstation  which  does  not  support  SGML,  then  there  must  be  a 
capability  to  extract  the  text  from  an  IGES  General  Note  entity 
(or  a  proprietary  text  editor/processor)  and  insert  the  appropri¬ 
ate  SGML  markup  codes.  Similarly,  once  the  parts  list  data  has 
been  extracted  from  an  IGES  file  sorted,  and  reformatted  using 
separate  application  software,  SGML  must  access  and  incorporate 
the  intermediate  parts  list  file. 

5.9.2  IGES.  The  CAD  design,  created  by  a  proprietary  sys¬ 
tem,  must  first  be  translated  into  IGES  format  for  transmission 
to  the  authoring  system.  For  the  sake  of  the  example,  however, 
it  is  assumed  that  the  illustration  will  be  abstracted  from  the 
full  design,  meaning  that  some  of  the  CAD  graphics  must  be 
deleted,  along  with  much  of  the  annotation  and  part  of  the 
structural  entity  data.  At  the  same  time,  the  parts  list  data 
must  be  extracted  from  the  appropriate  IGES  entity  (which  will 
not  exist,  except  as  a  General  Note,  until  the  release  of  PDES) , 
and  reformatted.  The  entire  product  must  be  compacted  into  a 
storage  format  small  enough  for  efficient  inclusion  in  the  text 
document.  Some  of  this  might  be  done  as  an  ancillary  product 
during  the  CAD  design  process.  However,  most  of  it  -  including 
image  extraction/enhancement  and  data  compaction  -  would  be 
accomplished  at  a  graphics  workstation  subsequent  to  the  CAD 
process . 

5.9.3  VDI  ( CGI) .  The  role  which  VDI  would  play  in  this 
process  is  primarily  a  function  of  the  hardware  interfaces  in  the 
authoring  system's  text/graphics  equipment  configuration.  VDI 
would  not  be  required  to  read  in  the  IGES  formatted  graphics 
source  data,  and  VDI's  low  level  graphics  commands  would  be  com¬ 
pletely  inadequate  to  handle  the  image  extraction/enhancement 
requirements  posed  by  this  example.  VDI,  while  useful,  would  not 
be  needed  at  all  in  a  dedicated  system  specifically  constructed 
for  data  interfacing  such  as  this. 


5.9.4  GKE/CORE.  One  or  the  other  of  these  higher  level 
graphics  languages  would  probably  be  needed  to  prepare  the  illus¬ 
tration  for  incorporation  in  the  technical  document.  This  might 
include  image  enhancement,  addition  of  background,  etc.  Two- 
dimensional  GKS  would  undoubtedly  be  the  preferred  language  in 
this  example.  However,  application  software  would  be  needed  to 
translate  the  IGES  source  data  into  a  format  the  GKS/CORE  program 
could  manipulate. 

5.9.5  VDM  ( CGM ) .  The  compacted  graphics  data,  plus  the 
narrative  text  and  parts  list  data,  must  be  stored  in  some  format. 
If  NAPLPS  is  not  used  for  data  transmission,  then  a  VDM  file 
format  would  be  the  preferred  choice  for  storage,  and  VDI  would 

be  used  to  facilitate  a  GKS/ VDM  interface.  Alternatively,  a  GKS 
metafile  could  be  used  for  storage,  if  GKS  were  used  for  image 
enhancement.  If  NAPLPS  is  used  for  transmission,  then  a  propri¬ 
etary  storage  format  might  be  used,  or  the  NAPLPS  translator 
might  generate  a  VDM-formatted  data  file. 

5.9.6  NAPLPS .  The  role  of  NAPLPS  in  either  this  example  or 
the  more  generalized  text/graphics  transmission  problem  is  a 
function  of  several  factors.  ASCII  characters  are  a  subset  of 
the  complete  NAPLPS  standard;  hence,  a  NAPLPS  translator  can  be 
used  for  transmitting  SGML-coded  text  even  if  none  of  the  other 
NAPLPS  graphics  capabilities  are  used.  But  the  intended  use 
(e.g.,  presentation  vice  simple  data  handling),  the  mix  of  text 
and  graphics,  the  need  for  compact  volume,  and  translation  pro¬ 
blems  all  need  to  be  considered.  Although  some  authors  have 
proposed  NAPLPS  as  a  universal  data  exchange  format,  this  concept 
is  not  completely  accepted.  It  is  also  possible  that  NAPLPS 
would  only  be  used  for  high  volume,  long  distance  data  transmis¬ 
sion,  where  data  compression  is  a  more  significant  issue.  Direct 
transmission  could  be  used  to  pass  SGML  text  streams  and  VDM  or 
GKS  metafile  data  files  among  locally  networked  devices  much  more 
simply  than  would  be  needed  for  yet  another  data  translation  into 
NAPLPS  code.  Certain’ y  long  haul  communications  could  also  be 
accomplished  without  NAPLPS,  in  which  case  VDM  (and  VDI)  would  be 
highly  desirable  for  data  compaction  and  equipment  interfacing. 

Whether  NAPLPS  is  used  or  not,  some  form  of  communications 
protocol  would  be  required  to  handle  the  actual  interconnection 
of  various  output/display,  storage  and  processing  hardware. 

Here,  too,  there  are  unresolved  standarization  issues,  with 
active  competition  between  proprietary  approaches  and  those 
compatible  with  ISO's  open  system  interconnection  model.  Most 
major  American  corporations,  and  many  foreign  firms,  have  adopted 
approaches  compatible  with  the  ISO  model  and  protocols;  AT&T  and 
General  Motors  in  particular  have  done  so.  However,  IBM's  System 
Network  Architecture  (SNA)  is  an  important  de  facto  competitor. 
Other  proprietary  approaches  are  unlikely  to  survive,  however. 

The  X.400  Messaging  recommendations  of  the  International  Tele¬ 
phone  and  Telegraph  Consultative  Committee  (CCITT)  also  represent 
an  important  standardization  thrust  for  local  and  wide  area  net¬ 
working.  Issues  associated  with  these  topics  are  particularly 


important,  not  only  because  of  the  desire  to  communicate  graphics 
and  text  electronically,  but  because  the  potential  volume  of 
graphics  and  text  data  will  impose  special  data  handling  require¬ 
ments  such  as  high  bandwidth  and  interactive  information  handling 
capability. 

6.  OPTIONS  FOR  POD  ACTION.  At  this  point  in  time,  DoD  has  a 
wide  range  of  options  available  for  action  (or  inaction)  in  the 
graphics  and  text  standards  arena.  The  Congressional  requirement 
to  proceed  with  development  of  a  technical  data  locator/index 
system,  the  consequent  accelerated  plans  for  automation  of  engi¬ 
neering  drawing  repositories,  and  the  internal  DoD  pressure  for 
cost  effective  technical  data  automation  does  not  necessarily 
mandate  action  on  standardizaton.  Thus  far,  DoD  has  "accepted"  - 
i.e.,  recognized  -  Gen Code  and  IGES;  there  has  been  some  measure 
of  official  DoD  support  for  GenCode  adoption  -  i.e.,  preferred 
usage  -  but  relatively  less  for  IGES.  Principal  supporters  for 
these  or  other  graphics/text  standards  have  been  at  Service  level 
Continuing  this  pattern  and  taking  no  new  or  expanded  action  at 
DoD  level  would  constitute  the  "take  no  action"  option.  At  the 
opposite  extreme  lies  the  option  of  active  development  of  com¬ 
plete  DoD-standard  CAD/CAM,  graphics  and  text  software  languages, 
much  as  was  done  with  Ada. 

6.1.  Take  No  Action.  This  option  would  allow  industry 
standards  to  evolve  at  their  own  pace,  and  in  accordance  with 
user  needs.  Lack  of  a  coordinated  DoD  position  suggests  that  DoD 
would  generally  follow  the  market,  rather  than  lead  it.  Indivi¬ 
dual  Service  actions,  such  as  the  Air  Force  initiative  that  led 

to  the  creation  of  IGES,  would  continue,  and  might  have  a  signifi¬ 
cant  market  impact,  although  -  again,  like  IGES  -  this  impact 
would  probably  be  slow  to  materialize.  The  Military  Departments 
would  maintain  their  present  programs  to  automate  individual 
logistics  and  technical  data  functions,  such  as  engineering 
drawing  repositories  but,  without  the  emphasis  of  a  coordinating 
process,  there  would  be  limited  support  for  integration  and 
standardization  of  these  "islands  of  automation."  Because  there 
is  a  requirement  to  support  a  transition  from  current  paper-based 
to  future  digital  information  management  -  meaning  a  requirement 
for  concurrent  maintenance  of  hard-copy  drawings/manuals  and  new 
digital  data  bases  -  there  will  be  too  many  competing  demands  for 
Service  time  and  resources  to  focus  significant  attention  on  new, 
even  "experimental,"  issues  such  as  graphics  and  text  standardi¬ 
zation.  The  CALS  study  has  already  shown  that  the  Take  No  Action 
option  has  failed  to  adequately  identify,  much  less  satisfy, 
long-term  DoD  requirements,  and  it  is  unlikely  that  continuation 
of  this  option  would  effectively  remedy  this  problem,  even  with 
CALS  study  results  to  guide  individual  Service  programs. 

6.2.  Adoption  Policy  and  Increased  ANSI  Committee 
Participation .  A  clear  expression  of  DoD  preference  for  one  or 
more  standards,  signed  at  Under  Secretary  or  higher  level,  would 
not  only  point  a  direction  for  Service  implementation  actions  to 
follow,  but  would  also  send  a  signal  to  industry  that  would 
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accelerate  development  of  the  identified  standard(s).  This  is 
the  path  NAVSEA  has  chosen  with  IGES.  Increased  participation  by 
DoD  personnel  on  the  ANSI  technical  working  groups  which  develop 
these  standards  would  also  accelerate  development,  and  provide  an 
opportunity  to  influence  the  direction  of  development.  This 
would  have  the  greatest  impact  on  a  standard  such  as  IGES,  where 
major  avenues  of  basic  development  remain  to  be  exploited.  The 
absence  of  additional  funding,  however,  would  still  present  a 
barrier  to  some  of  the  development  efforts  which  are  required;  ;  '/ 
is  not  self-evident  that  this  option  would  be  adequate  to  gener¬ 
ate  a  significant  increase  in  Service  funding,  or  that  current/ 
increased  funding  would  be  applied  toward  a  common  development 
and  implementation  strategy.  Equally  significant  is  the  fact 
that  in  some  areas  there  is  still  no  clear  choice  for  the 
preferred  standard;  for  example,  between  GKS  and  CORE  for  some 
graphics  applications,  or  between  NAPLPS  and  VDM  for  graphics 
data  exchange  andstorage.  In  some  areas  (e.g.,  IGES,  SGML/ Gen- 
Code)  ,  this  option  represents  an  improvement  over  taking  no 
action,  but  is  still  inadequate  to  meet  CALS  objectives;  in  other 
areas  this  option  might  foreclose  an  avenue  DoD  should  exploit. 

6.3.  DoD  Funding  for  Development  and  Demonstration  Projects. 
Under  this  option,  DoD  would  target  funding  for  development  and 
test/prototyping  of  appropriate  industry  standards.  This  option 
would  offer  an  opportunity  to  compare  standards  where  applicabili¬ 
ty  or  preference  is  unclear,  as  with  CORE  and  GKS  in  the  training 
environment.  Equally  important,  it  would  offer  an  opportunity  to 
accelerate  standards  integration,  such  as  the  problem  of  data 
transfer  from  CAD/CAM  to  automated  authoring  systems.  This  major 
area  of  CALS  interest  would  otherwise  continue  to  trail  the 
standards  development  process,  as  it  has  heretofore.  Under  this 
option,  demonstration  projects  and  development  efforts  (which 
would  include  test/validation)  would  be  undertaken  and  managed  by 
individual  Service  project  offices,  with  review  and  limited 
coordination  at  OSD-level.  This  would  allow  targeting  of  funds 
into  high  leverage  CALS  thrust  areas,  without  necessitating 
direct  hands-on  management  by  OSD.  It  would  also  facilitate 
interservice  planning  and  coordination,  as  well  as  use  of  the  new 
DoD  Software  Engineering  Institute,  DARPA,  and  other  federal 
agencies  such  as  NASA  and  the  Department  of  Energy  (which  are 
major  IGES  supporters) ,  for  joint  efforts  in  furtherance  of  over¬ 
all  DoD  objectives  for  CALS.  The  two  principal  benefits  of  this 
option  are  accelerated  (and  more  coordinated)  development  of 
standards  meeting  DoD  needs,  and  implementation  follow-through  - 
that  is,  practical  application  of  the  standards  in  a  field  envi¬ 
ronment  where  utility  and  limitations  can  be  adequately  explored. 
It  would  also  provide  a  vehicle  to  define  changes  and  extensions 
to  the  standards,  identify  necessary  and  sufficient  subsets  of 
features,  and  test  proposed  applications.  The  principal  short¬ 
coming  of  this  option  is  its  implicit  deferral  of  an  expressed 
DoD  preferance  for  a  particular  standard,  which  might  delay 
action  by  industry  to  prepare  itself  to  meet  eventual  DoD  require 
ments  for  use  of  these  standards. 
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6 .4  DoD  Structure  to  Guide  Development  and  Implementation. 
The  use  of  funding  controls  and  project  review/coordination  pro- 
vides  one  approach  to  channeling  Service  actions  toward  satisfy¬ 
ing  overall  CALS  objectives.  The  establishment  of  a  more  formal 
structure,  such  as  a  technical  steering  committee,  or  a  lead 
Service  project  office,  would  offer  an  even  stronger  mechanism. 
Made  up  of  the  principal  government  and  industry  technical 
experts  and  users,  a  steering  committee  could  develop  and  coordi¬ 
nate  implementation  of  a  detailed  plan  of  action  leading  to  both 
completion  and  adoption  of  the  best  mix  of  graphics  and  text 
standards  for  DoD.  Meeting  regularly  to  review  progress  on  the 
implementation  actions  which  they  are  individually  responsible 
for,  the  members  of  such  a  committee  could  guide  requirements 
definition  within  DoD,  and  could  participate  collectively  in  the 
industry-wide  development  of  the  standards  themselves.  A 
formally  constituted  committee  would  focus  effort  and  attention 
in  a  fashion  the  "normal"  organization  structure  could  not. 
Participation  of  industry  representatives  in  such  a  committee 
would  help  to  ensure  that  DoD  actions  proceed  in  concert  with 
those  of  industry  and  the  applicable  standardization  bodies. 
Shortcomings  include  committee  management  bureaucracy  and  the 
potential  for  self-perpetuation.  A  lead  Service  project  office, 
supported  by  technical  advisors  from  other  DoD  components  and 
industry,  could  provide  an  even  stronger  focus  for  coordinated 
development  of  an  overall  DoD  strategy.  By  virtue  of  a 
continuing,  full-time  commitment,  ideally  under  a  direct  mission 
charter  from  OSD,  a  project  office  could  pursue  CALS  standardi¬ 
zation  objectives  with  greater  coherence  and  emphasis.  While 
such  an  approach  could  be  expected  to  produce  more  positive 
results  than  a  steering  committee  structure  alone,  it  would 
require  dedication  of  manpower  resources  over  and  above  what 
would  be  required  to  manage  a  program  of  similar  breadth  (though 
lesser  depth)  through  either  the  committee  approach  or  the 
standard  organization  structure  approach. 

6 . 5  Mandate  Usage  of  Relevant  Standards  Within  DoD  and  for 
New  Defense  Contracts.  This  option,  the  effects  of  which  were 
explored  early  in  the  CALS  project,  would  present  industry  with  a 
clear  DoD  commitment  to  the  mandated  standards.  Some  of  the 
potential  problems  posed  during  the  CALS  review  could  be  avoided 
by  being  more  selective  in  the  choice  of  standards  mandated, 
providing  a  longer  transition  period  with  exceptions  and  escape 
clauses,  and  accepting  the  requirement  for  DoD  funding  of  some  or 
all  of  the  additional  costs  incurred  by  industry  in  complying 
with  the  requirement.  Except  where  a  clear  preference  for  a 
well-defined  standard  has  already  emerged,  such  an  action  by  DoD 
would  likely  provoke  a  measure  of  opposition,  both  among  the 
Military  Departments  and  from  industry.  And  except  where  the 
standard  is  complete,  such  a  commitment  by  DoD  would  entail 
technical  risk  which  could  be  difficult  to  justify  on  the  basis 
of  the  substantial,  but  as  yet  unquantif iable ,  long-term  economic 
benefits  that  are  potentially  available. 
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6.6  Develop  and  Publish  Separate  DoD  Graphics  and  Text 
Standards"  Under  this  option,  an  activity  or  activities  within 
DoD  would  undertake  the  development  of  MIL-STD  documents  which 
satisfy  DoD  requirements  for  a  standard,  integrated  product  defi¬ 
nition,  graphics,  and  text  language,  including  data  exchange 
formats.  Although  such  an  undertaking  would  presumably  build  on 
one  or  more  existing  industry  (nongovernment)  standards  such  as 
SGML  and  IGES,  it  could  theoretically  develop  a  completely  new 
approach.  Although  obviously  a  massive  and  time-consuming  under¬ 
taking,  such  a  course  of  action  is  at  least  technically  feasible. 
It  has  the  advantage  of  being  able  to  confront  directly  the  known 
and  supposed  deficiencies  of  existing  industry  standardization 
efforts,  and  of  avoiding  some  of  the  delays  which  those  standards 
are  experiencing  as  they  proceed  through  the  national/inter¬ 
national  review  and  approval  process.  This  option  is  most 
attractive  in  those  cases  where  the  current  proposed/existing 
standard  is  incomplete,  since  it  offers  a  vehicle  whereby  a 
single  complete  language  and/or  data  exchange  format  could  be 
established  for  use  across  Service  lines  within  DoD,  as  well  as 
among  defense  contractors,  and  between  contractors  and  government 
However,  the  obstacles  to  adopting  this  option  are  monumental, 
and  the  benefits  are  not  sufficiently  well  quantified.  Although 
it  may  be  both  necessary  and  appropriate  to  develop  interim 
supplementary  DoD  standards  as  unique  DoD  requirements  become 
more  clearly  defined  (e.g.,  incorporation  of  logistics  data 
entities  in  IGES),  a  completely  separate  DoD  effort  cannot  be 
justified  at  this  point  in  time. 


7.  RECOMMENDATIONS  FOR  DOD  ACTION.  The  preceding  discussion 
makes  it  clear  that  no  single  option  is  adequate  to  address  the 
range  of  graphics  and  text  standards  in  which  DoD  has  an  interest 
It  is  equally  clear  that  neither  of  the  two  extreme  options  - 
taking  no  action,  or  taking  totally  independent  action  -  is  a 
viable  choice  for  any  of  these  standards.  The  principal  conclu¬ 
sion  that  can  be  drawn,  and  the  resulting  principal  recommenda¬ 
tion,  is  that  the  unresolved  issues  associated  with  graphics/text 
standardization  are  sufficiently  complex  that  some  type  of  formal 
DoD  management  structure,  such  as  a  project  office,  should  be 
tasked  to  pursue  a  plan  for  implementing  selected  standards, 
actively  supporting  further  development  efforts,  and  managing  a 
mix  of  studies  and  demonstration  projects  to  address  the  ques¬ 
tions  posed  in  this  paper. 


7.1.  Principal  Findings.  With  respect  to  the  product 
definition,  graphics,  and  text  standards  discussed  in  this  paper, 
the  following  conclusions  have  been  reached: 


a.  SGML  and  GKS  are  sufficiently  close  to  formal  approval, 
and  widely  enough  accepted  in  industry,  that  a  formal  DoD 
commitment  to  their  use  should  be  made.  However,  issues  such  as 
a  DIF  interface  and  the  GKS/CORE  choice  for  three-dimensional 
graphics  must  still  be  addressed,  and  an  implementation  transi¬ 
tion  period  must  be  allowed  for  both  DoD  and  industry. 
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b.  Increased  DoD  activity,  including  funding  of  selected 
demonstration  projects,  could  accelerate  development  of  several 
standards  which  have  the  potential  for  satisfying  DoD  and  indus¬ 
try  needs.  This  includes  VDI,  VDM  (including  resolution  of  the 
choice  between  VDM  and  NAPLPS),  PHIGS,  and  IGES.  This  is  parti¬ 
cularly  true  in  the  case  of  IGES,  which  is  the  accepted  standard 
for  exchanging  CAD/CAM  product  definition  data,  but  which 
requires  considerable  additional  development,  including  identi¬ 
fication  of  development  priorities. 

c.  Time  will  be  required  to  develop,  tailor,  validate, 
adopt,  and  implement  the  complete  family  of  graphics  and  text 
standards  needed  to  satisfy  DoD  requirements.  Digital  data 
exchange  cannot  and  should  not  be  held  in  abeyance  until  these 
actions  have  been  accomplished.  Data  exchange  using  proprietary 
formats,  interim  or  partial  standards,  or  program-peculiar  speci¬ 
fications  should  be  encouraged  until  such  time  as  the  necessary 
standards  are  in  place. 

d.  Tests  and  demonstration  projects  are  needed  to  resolve 
questions  of  standards  applicability  to  DoD  requirements.  For 
example,  although  GKS  appears  to  be  the  graphics  language  stan¬ 
dard  of  choice  for  most  automated  authoring  system  applications, 
a  three-dimensional  standard  such  as  CORE  may  be  more  suitable 
for  selected  applications,  such  as  training  material  or  mainten¬ 
ance  aids.  The  ability  of  NAPLPS  to  adequately  handle  volume 
transmission  of  text  and  graphics  data  among  automated  authoring 
systems  should  be  tested;  in  this  context,  the  applicability  of 
VDM  should  be  explored. 

e.  No  graphics  or  text  standard  is  totally  device  indepen¬ 
dent,  not  even  those  such  as  VDI  and  SGML  which  are  intended  to 
satisfy  this  criterion.  For  some,  such  as  IGES,  the  development 
and  validation  of  translators  is  a  major  obstacle  to  widespread 
use.  DoD  must  be  prepared  to  make  a  significant  contribution  of 
time,  funds,  and  other  resources  to  address  this  problem  if  early 
successful  application  of  these  standards  in  weapon  system  acqui¬ 
sition  programs  is  to  be  achieved. 

f.  The  biggest  largely  unexplored  area  which  must  be 
addressed  to  satisfy  CALS  objectives  is  the  interfacing  of  stan¬ 
dards,  such  as  the  use  of  IGES  data  (or  "abstracted  IGES"  data) 
as  input  to  a  GKS-based  graphics  subroutine  embedded  in  a 
GenCode/SGML  file.  Prior  to  the  beginning  of  the  CALS  project, 
applications  such  as  this  had  been  given  only  limited  considera¬ 
tion.  Both  the  theory  and  the  practice  of  this  issue  require 
considerable  additional  attention,  beginning  with  some  controlled 
tests,  followed  by  a  series  of  substantive  demonstration  pro¬ 
jects  . 

g.  Graphics  and  text  standards  alone  are  not  enough. 
Communications  protocols,  data  base  management  standards,  neutral 
query  languages,  and  other  standarization  issues  must  also  be 
addressed . 


h.  For  a  significant  period  of  time  DoD  will  have  to  func¬ 
tion  in  a  transitional  mode.  Old,  paper-based  logistics  and 
technical  data  must  be  maintained;  some  will  be  converted  to 
digital  form  through  both  standard  and  non-standard  means,  but 
(usually)  only  on  an  as-needed  basis,  for  conversion  is  costly 
and  resource  intensive.  New  data  will  not  all  be  delivered  in 
digital  form,  for  industry  is  also  in  a  transitional  mode,  albeit 
further  advanced  than  DoD. 

7.2  Recommendations .  Based  on  the  above,  the  following  recommen¬ 
dations  for  DoD  action  are  made: 

a.  DoD  should  establish  a  Project  Office  in  one  of  the 
Services  to  manage  a  CALS  Standardization  Implementation  Program. 
Actions  undertaken  as  a  part  of  this  program  would  be  accomplish¬ 
ed  through  a  mix  of  direct  effort  by  the  Project  Office,  contrac¬ 
tual  support  acquired  through  a  budget  administered  by  the 
Project  Office,  and  support  provided  by  each  of  the  Services  and 
coordinated  by  the  Project  Office. 

(1)  The  Project  Office  should  be  operated  by  one  of  the 
Services,  under  a  direct  OSD  charter.  A  Technical  Advisory  Group 
including  representatives  from  the  DoD  components,  selected  other 
federal  agencies  (such  as  NBS,  DOE,  NASA,  GPO) ,  and  defense 
industry  associations,  under  OSD  chairmanship,  should  review  and 
coordinate  the  Project  Office's  plans  and  programs. 

(2)  The  Project  Office  would  participate  in  development 
and  maintenance  of  CALS-related  industry  (non-government) 
standards  through  membership  in  the  appropriate  ANSI  and  ISO 
technical  committees.  A  DoD-internal  coordination  group,  perhaps 
modeled  on  the  Data  Exchange  Committee  established  by  General 
Motors  to  guide  and  control  IGES  implementation  within  GM,  should 
be  established  to  link  the  CALS  Project  Office,  the  Military 
Departments  and  Agencies,  and  OSD  at  the  working  level.  Through 
this  coordination  group,  interfaces  with  the  Defense  Standardi¬ 
zation  and  Specification  Program  (DoDD  4120.3)  as  well  as  all 
CALS-related  projects  would  be  maintained. 

(3)  The  Project  Office  would  define,  justify,  and  manage 
expenditure  of  logistics  R&D  funding  required  to  accomplish  the 
CALS  Standardization  Program. 

(4)  The  Project  Office  would  directly  manage,  or  parti¬ 
cipate  in  the  management  of  pilot/demonstration  programs,  and 
would  review  and  coordinate  on  full-scale  Service  implementation 
programs  (such  as  DSREDS/EDCARS ,  ATOS,  etc.).  Through  its  coordi¬ 
nating  function,  it  would  also  serve  as  a  de  facto  architectural 
control  board  for  individual  Service-developed  CALS  architec¬ 
tures,  as  well  as  their  interfacing  across  Service  lines. 

(5)  The  Project  Office  would  coordinate  development  by 
the  Services  and  LOGDESMAP  of  DoD-unique,  CALS-related  standardi- 


zation  programs  such  as  development  of  an  acquisition  logistics 
data  element  dictionary  (in  MIL-STD-1388-2A,  or  elsewhere,  as 
appropriate)  consolidating  data  requirements  in  MIL-STD-1388-2A 
and  other  Military  Standards,  revision  of  DIDs  to  facilitate 
neutral-formatted  digital  delivery  of  data,  preparation  of  hand¬ 
books  and  training  materials,  etc. 

(6)  The  Project  Office  would  prepare  a  Military  Standard 
for  management  of  CALS  information  transmission  and  access.  This 
standard  would  define  requirements  for  hardware  compatibility, 
software  and  data  exchange  transparency/portability,  communica¬ 
tions  and  delivery  media,  and  data  base/network  access  for  tech¬ 
nical  data  packages  and  engineering/logistics  data  prepared  in 
accordance  with  standards  such  as  MIL-STD-1388-2A  or  DoD-STD- 
100C. 

b.  DoD  should  announce  its  adoption  (not  merely  acceptance) 
of  SGML  for  all  technical  documentation  text  processing  func¬ 
tions,  and  GKS  for  all  two-dimensional  technical  documentation 
graphics  functions,  with  the  earliest  practical  implementation. 

An  incentive  program  should  be  developed  which  would  encourage 
defense  contractors  to  make  a  similar  commitment.  A  phased 
implementation  program  should  be  developed  for  application  of 
these  standards  both  within  DoD,  and  for  contractor-developed 
material . 

c.  DoD  should  announce  its  intention  to  actively  promote  the 
development  and  implementation  of  IGES  for  product  definition 
exchange  through  incentive  programs,  funding  of  demonstration 
projects,  and  formal  validation  of  translators.  Although  it  is 
premature  for  DoD  to  fully  adopt  IGES,  DoD  should  exploit  every 
opportunity  to  incorporate  IGES  compatibility  wherever  possible 
for  digital  delivery  of  CAD/CAM  product  definition  or  engineering 
drawing  data.  DoD  should  announce  now  its  intention  to  adopt 
IGES  following  release  of  the  "new"  Product  Definition  Exchange 
Specification  by  the  National  Bureau  of  Standards.  As  an  interim 
measure,  DoD  should  publish  an  IGES  entity  schedule  to  encourage 
(but  not  enforce)  contractor  compliance  with  the  current/soon-to- 
be-released  versions  of  IGES.  This  schedule  should  be  patterned 
on  that  established  by  NAVSEA,  which  in  turn  was  based  upon  the 
IGES  compliance  schedule  that  General  Motors  is  imposing  upon  its 
CAD/CAM  vendors . 

d.  Through  active  participation  in  ANSI/ISO  technical 
committees  and  funding  of  research  studies,  DoD  should  support 
and  accelerate  development  of  industry  standards  as  follows: 

(1)  Major  emphasis  -  Development  of  IGES  to: 

(a)  incorporate  logistics  data  in  PDES. 

(b)  develop  translator  validation  procedures,  and 
develop  test  data  for  Version  2. 1/3.0 

and  PDES . 
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(c)  accelerate  or  initiate  further  extensions 
for  a  new  "PDES  Version  2.0"  including: 
geometry  and  product  definition  data  for 
electronics  and  printed  circuit  boards, 
electrical  cables  and  harnesses,  and 
hydraulics;  product  definition  requirements 
for  manufacturing  processes  other  than 
machine  shops;  incorporation  of  CAE  tools. 

(2)  Medium  emphasis  -  Standards  Interfacing. 

(Rationale:  This  area  is  accorded 

less-than-ma jor  emphasis  as  a  standards 
development  effort  because  it  is  perceived  that 
the  most  significant  accomplishments  in  this 
area  will  emerge  as  a  by-product  of  CALS  pilot/ 
demonstration  projects  which  apply,  but  are  not 
aimed  specifically  at  developing,  interfacing 
standards.)  Specific  thrust  areas  include: 

(a)  IGES,  VDM  (CGM),  GKS ,  SGML. 

(b)  NAPLPS,  SGML 

(c)  DIF,  SGML. 

(d)  Use  of  various  communications  protocols 
(such  as  GM/MAP,  ETHERNET,  IBM/SYTEK)  for 
transmission  of  standard  format  text/ 
graphics  data  files. 

(3)  Minor  emphasis  -  Development  of  other  text  and 
graphics  standards.  (Rationale:  These 
standards  are  already  under  active  development. 

DoD  can  accelerate  that  development,  but  is  not 
yet  in  a  position  to  define  substantive  differ¬ 
ences  in  required  content.)  These  include: 

(a)  Three-dimensional  GKS 

(b)  VDI  (CGI) 

(c)  PHIGS 

e.  Through  active  participation  in  ANSI/ISO  technical 
committees  and  continuing  funding,  DoD  should  support  research 
and  development  of  communication  protocols  (especially  bridging), 
intelligent  gateways,  network  topology,  distributed  data  bases, 
hardware/software  transparency,  and  neutral  data  bases  and  data 
base  management  systems.  Although  not  directly  related  to 
graphics/text  standardization,  these  issues  all  must  be  studied 
to  most  effectively  exploit  digitized  delivery  of  graphics  and 
text  data.  Among  the  related  topics  which  should  also  be 
explored  are  access  control  and  security  for  classified  or  pro¬ 
prietary  information;  traffic  characteristics,  data  volumes,  and 
resource  requirements  for  CALS-related  data;  interfaces  and 
demands  to  be  placed  by  CALS  on  the  Defense  Data  Network;  tech¬ 
niques  and  auditability  for  data  base  updates;  and  the  relative 


efficiencies  of  horizontal  or  vertical  partitioning,  or  redundant 
storage  within  a  distributed  system. 

f.  DoD  should  seek  wherever  possible  to  apply  text,  gra¬ 
phics,  and  product  definition  standards  in  both  demonstration 
projects  and  full-scale  implementation  programs  involving  digital 
delivery  and  retrieval  of  weapon  system  acquisition  and  support 
data.  These  demonstration  projects  would  be  aimed  at  exploring 
the  full  range  of  hardware,  software,  and  telecommunications 
technology,  plus  the  contractual  and  managerial  policies/proce¬ 
dures  needed  to  satisfy  overall  CALS  objectives.  The  use  of 
standard  languages,  data  exchange  formats,  or  communication 
protocols  should  be  viewed  as  one  important  element  of  a  complete 
demonstration  project,  although  not  necessarily  as  the  principal 
focus  of  the  project.  Second,  these  demonstration  projects 
should  also  be  aimed  at  defining  alternatives  and  options  for 
management  of  acquisition  logistics  data,  from  which  new 
requirements  for  standards  development  may  emerge.  Examples 
include: 

(1)  Digital  transmission,  first  by  tape  and  later 
electronically,  of  CAD  data  from  multiple 
subcontractors  for  on-line  integration  with 
next-higher-assembly  CAD  data  at  a  prime 
contractor,  followed  by  transmission/application 
in  a  CAM  environment,  digital  transmission/stor¬ 
age  at  a  government  drawing  repository,  and 
on-line  retrieval  by  a  maintenance  or  engineering 
activity. 

(2)  An  automated  authoring  system  electronically 
linked  to  a  CAD/CAM  system  for  technical 
illustrations  with  on-line  update  capability  and 
electronic  delivery  of  technical  documents  to 
depot  and  intermediate  maintenance,  or  wholesale/ 
retail  supply  organization. 

g.  Demonstration  projects  and  full-scale  Service  implementa¬ 
tion  programs  such  as  the  above  are  already  underway,  or  planned, 
including  many  of  the  elements  of  a  successful  CALS  strategy. 
Examples  include  DSREDS/EDCARS ,  ATOS,  NTIPS,  ICAM,  RAMP,  IDS,  etc. 
CALS  funding  should  be  applied  to  accelerate  them,  expand  their 
application,  and  redirect  them  where  appropriate  toward  objec¬ 
tives  such  as  end-to-end  (weapon  designer  to  manager/user)  system 
integration,  fully  automated  near  paperless  data  exchange,  and 
improved  application  of  the  automated  data  by  weapon  system 
designers,  manufacturers,  managers,  and  maintainers.  These  pro¬ 
grams,  as  well  as  new  demonstration  projects  specially  designed 

to  explore  CALS-related  issues,  should  be  used  as  test  beds  to 
develop  further  recommendations  concerning  digital  data  exchange 
standardization.  Among  the  open  questions  which  need  to  be 
addressed  are: 
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(1)  Specific  entity  limitations  of  IGES  for  different 
classes  of  weapon  components,  subsystems,  etc. 

(2)  The  limitations  of  two-dimensional  GKS  vice 
three-dimensional  CORE  for  use  in  development  of 
interactive  training  systems  and  maintenance  aids. 

(3)  Requirements  for  new  data  compression  techniques 
and  data  exchange  standards  to  support  high 
volume  electronic  transmission  of  engineering 
drawings,  technical  manuals,  and  other  CALS  data. 

(4)  The  adequacy  and  utility  of  NAPLPS  for 
transmission  of  technical  data  for  maintenance 
support  or  other  logistics  functions. 

7.3  Implementation  Schedule .  The  initial  action  undertaken 
by  the  new  CALS  Project  Office  should  be  development  of  an  imple 
mentation  roadmap  and  milestones  for  the  actions  listed  above. 
The  following  tentative  milestones  appear  reasonable,  assuming 
that  a  dedicated  staff  is  available  for  their  support: 

(1)  By  June  1985  - 

(a)  Establish  a  Technical  Advisory  Group  and 
publish  a  coordinated  Action  Plan. 

(b)  Begin  active  participation  in  ANSI/ISO 
technical  committees. 

(c)  Announce  DoD  adoption  of  SGML  and  GKS. 

(d)  Publish  IGES  entity  schedule  and  DoD  position 
statement  supporting  development  of  IGES/PDES 
for  1986  adoption. 

(2)  By  December  1985  - 

(a)  Publish  CALS  information  management  Military 
Standard,  as  described  in  subparagraph  7.2a(6). 

(b)  Assure  inclusion  of  logistics  entities  in  PDES. 
Complete  IGES  translator  validation  procedures, 
a  full  test  data  set  for  Version  2. 1/3.0  and  a 
preliminary  test  data  set  for  PDES,  and 
undertake  validation  of  existing  IGES 
translators  for  ten  major  CAD/CAM  systems. 

(c)  Preliminary  resolution  of  standards  interfacing 
issues,  including  demonstration  of  IGES/ SGML 
and  DIF/SGML  interfaces. 


(3)  By  December  1986  - 


(a)  Announce  DoD  adoption  of  PDES  (Early  1986). 

(b)  Through  NBS,  support  publication  of  a  draft 
"Version  2.0"  of  PDES  addressing  electronics 
and  printed  circuit  boards,  expanded 
manufacturing  applications,  and  language 
interfaces . 

(c)  Complete  validation  of  all  available  IGES 
translators . 

(d)  Publish  results  of  all  of  the  demonstration 
projects  described  in  subparagraph  7.2f 
(digital  delivery  and  retrieval  of  CAD  data, 
and  automated  authoring). 

7.4  Conclusions .  Standardization  of  graphics  and  text 
languages  and  data  exchange  formats  offers  significant  potential 
for  improvements  in  weapons  system  acquisition  and  logistics 
support.  However,  these  standards  are  incomplete,  and  only  SGML 
and  GKS  are  nearly  ready  for  full  adoption  by  DoD.  Most  require 
additional  development,  and  all  (including  SGML  and  GKS)  need 
additional  attention  to  interfacing  and  validation.  DoD  can  make 
a  major  contribution  to  completion  and  industry-wide  implementa¬ 
tion  of  these  standards,  while  at  the  same  time  advancing  CALS 
objectives,  by  committing  manpower  and  funding  to  development, 
validation  and  demonstration  of  these  standards.  Additional  work 
is  needed  to  define  the  details  of  these  actions  and  identify  the 
level  of  funding  support  needed.  NBS's  recent  three-year, 

$5  million  research  proposal  provides  an  overview  of  the 
text/graphics  standards  research  and  development  efforts  needed, 
but  does  not  provide  for  the  near-term  actions  that  DoD  should 
take  for  maximum  benefit.  DoD  should  move  promptly  to  better 
define  these  requirements  and  proceed  on  an  accelerated  schedule 
to  implement  a  program  of  graphics  and  text  standardization. 
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